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

Московский Государственный ИнститутЭлектронной Техники
Технический Университет
Факультет: МПиТК
Кафедра: ИПОВС
Пояснительная записка
к дипломному проекту
Тема: Программа регистрациипроцесса производства для автоматизированной системы управления предприятиемэлектронной промышленности
ДипломантЛяшко М.А. //
Руководительпроекта Брусникин Г.Н. //
КонсультантБрусникин Г.Н. //
Консультантпо технологической части Брусникин Г.Н. //
Консультантпо организационно-
экономическойчасти Пискунова Н.Н. //
Консультантпо производственно-
экологическойчасти Никулина И.М. //

Содержание
Введение
1.Состояние и тенденции развития АСУ ПП
1.1Опыт отечественной науки — ситуационные системы управления
1.1.2Применения ситуационного управления
1.2Manufacturing executing systems — перспективные автоматизированные системыуправления производственными процессами
1.2.1Общая характеристика MES-систем
1.2.2Блоки MES-систем
1.2.3Достоинства MES-систем
1.2.4Перспективы развития MES-систем
1.3Выводы
2.Постановка задачи
2.1Введение в предметную область. Анализ работы цехов ОАО Ангстрем
2.1.1Особенности технологического цикла производствапартий пластин
2.1.1.1Изделия, партии, технологические маршруты, маршрутные листы
2.1.1.2Регистрация процесса производства партий пластин
2.1.1.3Незавершенное производство
2.1.2 Общая схема управления
2.1.3Задержки в транспорте и обработке партий пластин
2.2Анализ требований к системе
2.3Рекомендации к разработке автоматизированной системы управленияпроизводственным процессом
2.4Предлагаемая архитектура автоматизированной системы управления производственнымпроцессом
2.4.1Общая схема управления
2.4.2Взаимодействие программы регистрации и персонала
2.4.3Реализация
2.4.4Управление обработкой партий
2.44.1 Понятие дисциплины очереди
2.4.4.2Предварительная схема дисциплины очереди
2.5Техническое задание на дипломный проект
2.6Выбор платформы и инструмента разработки программы
3.Разработка алгоритмов и программ
3.1Этапы объектно-ориентированного подхода
3.2Характерные свойства системы
3.3Выбранные объекты
3.4Алгоритм выполнения технологической операции
3.5Алгоритм формирования дисциплины очереди
3.6Использование библиотеки Microsoft Foundation Classes
4.Объектно-ориентированное программирование
4.1Введение
4.2Понятие жизненного цикла программного обеспечения
4.3Модели жизненного цикла программного обеспечения
4.4Анализ
4.5Проектирование
4.5.1Методы проектирования
4.5.2Объектно-ориентированная модель
4.5.3Процесс объектно-ориентированного проектирования
4.6Эволюция
4.7Сопровождение
4.8Заключение
5.Методика отладки и результаты работы программы
5.1Особенности тестирования программных продуктов
5.2Типичный процесс тестирования программногообеспечения
5.3Особенности задачи в приложении к тестированию программ
5.3.1Особенности среды программирования
5.3.2Основные факторы, влияющие на надежность разрабатываемой системы
5.3.2.1Контроль структуры программы
5.3.2.2Контроль чтения и записи переменных
5.4Результаты работы программы
6.Организационно-экономическая часть
6.1Введение
6.2Сетевая модель, ее основные элементы, правила построения
6.3Расчет параметров сетевой модели
6.4Основы оптимизации сетевого графика
6.5Анализ и оптимизация сетевой модели
6.6Выводы
7.Производственная и экологическая безопасность
7.1Введение
7.2Рабочее место программиста
7.3Вредные факторы на рабочем месте программиста и пользователя ЭВМ
7.4Нерациональное освещение
7.5Расчет общего освещения
7.6Электроопасность
7.7Требования по пожарной безопасности
7.8Меры по снижению уровня шума
7.9Защита от вредных излучений
7.10Параметры микроклимата в машинном зале
7.11Психофизиологические факторы
7.12Планировка рабочего места программиста и организацияработы с компьютером
7.13Выводы
Заключение
Списокиспользованной литературы
Приложение
/>/>Введение
Данныйдипломный проект выполнен на актуальную для предприятий, производящихполупроводниковые кристаллы, тему, тесно связанную с реальными планамипроизводства, решая практическую задачу по разработке и внедрению программногообеспечения автоматизированного управления производственным процессом. Посвоему содержанию дипломный проект соответствует современному уровню науки итехники.
Современноеполупроводниковое производство представляет собой сложныйорганизационно-технологический комплекс, который включает в себя одновременнуюобработку многих сотен партий полупроводниковых пластин, проходящих поразличным сложным, имеющим циклический характер, технологическим маршрутам сучастием большого числа специализированных единиц оборудования, расположенныхна различных производственных участках. Для эффективной работы производстванужно обеспечить управление транспортом и обработкой партий пластин, включающееучет технологически необходимых времен обработки и возможных временныхзадержек, учет приоритетов изготовления, мониторинг качества и сбор статистики,учет реставраций, связанных с исправление возможных несоответствий, учетвозможных сбоев в работе технологического оборудования и т.п.
Системауправления процессом производства должна быть построена таким образом, чтобыобеспечить разумный компромисс между желанием максимально загрузить имеющеесяоборудование (что неизбежно приводит к возникновению очередей на обслуживаниепри прохождении партий полупроводниковых пластин по технологическому маршруту) инеобходимостью обеспечить короткое время выполнения заказа (для чегонеобходимо, чтобы изготавливаемая партия пластин как можно меньше простаивала вочередях).
Системауправления производством должна быть оперативной: для типичного цеха необходимопринимать порядка 105 элементарных решений о транспорте партий ипорядка 109 решений по обработке пластин в месяц. Оперативностьсистемы управления подразумевает, что она должна базироваться на современныхкомпьютерно-сетевых технологиях, а сложность решаемых задач накладываеттребование «интеллектуальности» такой системы управления.
Впроцессе решения задачи создания программного продукта детально былирассмотрены особенности разработки программного обеспечения для промышленныхпрограммных продуктов. Они применяются для решения самых разных задач, таких,например, как системы с обратной связью, которые управляют или сами управляютсясобытиями физического мира и для которых ресурсы времени и памяти ограничены; системыуправления и контроля за реальными процессами (например, диспетчеризациявоздушного или железнодорожного транспорта). Системы подобного типа обычноимеют большое время жизни.
Втехнологической части разработки программных систем и программной документацииосвещены этапы решения задачи на ЭВМ, принципы тестирования программ и ихотладка. Целый раздел посвящен вопросам надежности программного обеспечения.
Ворганизационно-экономическом разделе рассчитан сетевой график разработкиавтоматизированной системы управления, определен критический путь, резервывремени событий и работ, проведена оптимизация сетевого графика по количествуисполнителей с целью уменьшения затрат на разработку системы.
Впроизводственно-экологическом разделе организации рабочего места программиста ипользователя ЭВМ рассмотрены вредные факторы, присутствующие на рабочем месте,психофизиологические факторы, требования к освещенности помещения, шуму,электро- и пожаробезопасности, спланировано само рабочее место и организацияработы программиста с компьютером.
Специальная часть:
Программа регистрации процесса производства дляавтоматизированной системы управления.
/>/>1. Состояние и тенденции развития АСУ ПП/>/>1.1 Опыт отечественной науки — ситуационные системыуправления
В1970-1980-х годах в отечественной прикладной науке возникло мощное направлениеисследований — разработка систем ситуационного управления [1-4]. Функционировалпостоянный межотраслевой научно-технический семинар, разрабатывалисьтеоретические и практические методы ситуационного управления. При разработкесистем ситуационного управления активно использовались теоретические методыискусственного интеллекта [5], теории автоматов [6], нечеткой логики [7,8] и т.п.
/>1.1.1 Общие принципыситуационного управления
Охарактеризуемкратко общие принципы работы ситуационного управления [1]. Общая схемаситуационного управления иллюстрируется Рис.1. Описание текущей ситуации,сложившейся на объекте управления, дается на вход Анализатора. Его задачасостоит в оценке сообщения и определении необходимости вмешательства системыуправления в процесс, протекающий в объекте управления. Если текущая ситуацияне требует такого вмешательства, то Анализатор не передает ее надальнейшую обработку. В противном случае описание текущей ситуации поступает в Классификатор.Используя информацию, хранящуюся в нем, Классификатор относит текущуюситуацию к одному или нескольким классам, которым соответствуют одношаговыерешения. Эта информация подается в Коррелятор, в котором хранятся все логико-трансформационныеправила (ЛТП). Список ЛТП задает возможности системыуправления воздействовать на процессы, протекающие в объекте управления. Корреляторопределяет то ЛТП, которое должно быть использовано. Если такое правилоединственное, то оно выдается для использования. Если же таких правилнесколько, то выбор лучшего из них производится после обработки предварительныхрешений в Экстраполяторе, после чего выдается решение о воздействии наобъект. Если Коррелятор или Классификатор не могут принятьрешения по поступившему описанию текущей ситуации, то срабатывает Блокслучайного выбора и выбирается одно из воздействий, оказывающих не слишкомбольшое влияние на объект.
Такиесистемы управления должны быть неизбежно открытыми. Они должны иметьвозможность корректировать свои знания об объекте и методах управления им. Вработе такой системы управления имеется два этапа:
1) этапобучения и настройки и 2) этап работы. На первом этапе собираются и обобщаютсяданные от технологов и формируются классы ситуаций и ЛТП. На второмэтапе неизбежно проводится дообучение системы управления./> />
Рис.1. Общая схема ситуационного управления
/>/>1.1.2 Применения ситуационного управления
Принципыситуационного управления нашли широкую сферу применения. Приведем некоторыепримеры практических разработок, в которых использовались принципыситуационного управления [1]:
Оперативноедиспетчерское управление погрузочно-разгрузочными работами в морском порту (Одесса,Калининград).
Оперативноеуправление перемещением по буровым специальных установок для производстватампонажных работ и буровых установок по пунктам бурения (Грозный).
Комплексзадач АСУ гражданской авиации (Рига).
Оперативноеуправление производственными участками на приборостроительных предприятиях (Устинов).
Оперативнаядиагностика заболеваний и назначение лечения (Баку).
В целомпринципы ситуационного управления близки к задачам управления производствомпартий в микроэлектронном технологическом процессе, и естественно использоватьсложившиеся в ситуационном управлении методы и подходы при разработке системыуправления производством партий в ОАО Ангстрем.
Прототипамисистемы управления производством партий в ОАО Ангстрем могут быть активноразрабатываемые в настоящее время за рубежом перспективные автоматизированныесистемы управления производственными процессами, Manufacturing executingsystems (фирма Consilium и др.) [9,10] и системы диспетчерского управления исбора данных (SCADA — системы). Эти системы краткохарактеризуются в следующих разделах.
/>/>1.2 Manufacturing executing systems — перспективныеавтоматизированные системы управления производственными процессами
/> 1.2.1 Общая характеристика MES-систем
MES-системывозникли из потребности оптимизации сложных производственных процессов, такихкак производство микроэлектронных интегральных схем, полупроводниковоепроизводство, производственные процессы в фармацевтической, текстильнойпромышленности, в производстве продуктов питания.
MES-системыпредставляют собой компьютерно-сетевые архитектуры (Рис.2,3), способствующиеэффективному управлению производственным процессом [9]. MES-системыпредоставляют информацию, которая обеспечивает оптимизацию производствапродукции от стадии заказа до выпуска конечной продукции. Используя точный сбортекущих данных, MES-система динамически отслеживает весь производственныйпроцесс: инициирует операции, при необходимости оперативно вмешивается впроцесс и ведет сбор данных об этом процессе. Функционирование MES-системыобеспечивает оперативное отслеживание постоянно меняющихся условий и устранениелишних затрат. MES-система осуществляет необходимое информационное обеспечениедля управления производством в интерактивном режиме.
MES-системыразрабатываются рядом фирм. Фирмы объединены в ассоциацию MESA. Эти фирмыизготовляют различные наборы программных продуктов, в соответствии стребованиями предприятий-заказчиков./> 1.2.2 Блоки MES-систем
Различают11 типов блоков, из которых может быть изготовлена конкретная MES система длятого или иного производства. Перечислим эти блоки:
Составлениерасписания операций (Operations/Detail Scheduling) — установление временнойпоследовательности действий для рассматриваемого производственного процесса наданном предприятии при заданных ресурсах. Составление расписания подразумеваетопределенную оптимизацию производственного процесса;
Распределениересурсов и слежение за ресурсами (Resource Allocation and Status) — распределениезаданий персоналу, машинам и установкам и отслеживание того, что они делаютсейчас, и того, что они только что сделали;
Диспетчеризацияэлементов производства (Dispatching Production Units) — подача команд длятранспорта материалов или заказов на определенные участки завода для того,чтобы начать какие-либо процессы или действия;
Управлениедокументооборотом (Document Control) — управление информацией и распределениеинформации о продуктах, процессах, установках и т.д.;
Отслеживаниегенеалогии продуктов (Product Tracking and Genealogy) — мониторинг прогрессаразвития создаваемых продуктов и партий, осуществляемый с целью отслеживанияполной истории изготавливаемых на заводе продуктов;
Анализэффективности производства (Performance Analysis) — сравнение результатовзавода с метриками, устанавливаемыми корпорацией, потребителями иорганизациями, регулирующими рыночные отношения;
Управлениеперсоналом (Labor Management) — управление использованием персонала с точкизрения квалификации, распределения обязанностей и потребностей производства;
Управлениеоборудованием (Maintenance Management) — планирование и выполнение работ поподдержке работоспособности установок и другого оборудования в соответствии спроизводственными целями завода;
Управлениетекущими производственными процессами (Process Management) — управление потокомработ на заводе в соответствии запланированными и текущими процессами;
Управлениекачеством (Quality Management) — отслеживание и анализ характеристик продуктови сопоставление их с желаемым идеалом;
Сбор иобработка данных (Data Collection/Acquisition) — мониторинг, обработка иупорядочивание данных о процессах, материалах и операциях, получаемых отперсонала, машин и систем управления.
/> 1.2.3 Достоинства MES-систем
Практикаприменения MES-систем демонстрирует следующие их достоинства:
уменьшениедлительности производственного цикла, в среднем на 45%;
сокращениевремени ввода (entry time), на 75% или больше;
уменьшениенезавершенного производства (НЗП), на 24%;
уменьшениебумажного документооборота между сменами, в среднем на 61%;
сокращениевремени проектирования (lead time), в среднем на 27%;
уменьшениеработы с бумажной документацией и потерь на копировальные работы, в среднем на56%;
уменьшениедефектности производимой продукции, в среднем на 18%./> 1.2.4 Перспективы развития MES-систем
Перспективыразвития MES-систем связаны с общими тенденциями развития компьютерных сетей. Программныепродукты MES-систем пишутся на объектно-ориентированных языках. Имеетсяопределенная тенденция к использованию MES-систем в географическираспределенных предприятиях (при этом производитель становится как бы ближе кзаказчику и к субподрядчикам) на основе использования передовых достиженийкомпьютерно-сетевых технологий (Рис.2,3). В США сформирован поддерживаемыйгосударством консорциум Solution for MES-Adaptable Replicable Technology (NIIIP/SMART),который предназначен для разработки стандартов для создания инфраструктурыраспределенных предприятий будущего.
/>
Рис.2. Современнаякомпьютерно-сетевая архитектура MES — системы
API — интерфейс прикладного программирования.
Application — пользовательское приложение.
Data Model — модельпредставления данных.
Data Communications — передача данных.
Database — база данных.

/>
Рис.3. Схема,иллюстрирующая перспективные тенденции развития MES-систем
Object Model — объектная модель.
Object Request Broker — обработчик запросов.
FireWall — система защиты от несанкционированного доступа.
API — интерфейс прикладного программирования.
Application — пользовательское приложение./>/>1.3 Выводы
Современноемикроэлектронное производство представляет собой сложный процесс. На уровнеотдельного цеха этот процесс включает в себя обработку партий полупроводниковыхпластин на установках, которые расположены на различных участках. Необходиматранспортировка партий между участками, необходим учет времен обработки партийна установках, возможных временных задержек обработки, необходим контролькачества партий, исправление дефектов обработки, учет возможных выходов изстроя оборудования.
Внастоящее время интенсивно развиваются компьютеризированные системы управленияпроизводственными процессами. Более того, предприятия, не использующиесовременные технологии, рискуют оказаться в роли «вечно отсталых» и,в конечном итоге, могут не выдержать рыночной конкуренции. Поэтому можно суверенностью сказать: разработка АСУПП на ОАО «Ангстрем» необходима. Приразработке такой системы целесообразно использовать подходы, методы и принципыпостроения ситуационных систем управления, принципы создания современныхкомпьютерно-сетевых MES-систем и SCADA-систем.
/>/>2. Постановка задачи
Предлагаетсясхема системы управления производством партий интегральных схем на предприятииэлектронной промышленности. Предложена общая структура системы управлениятранспортом и обработк/>ой партий полупроводниковыхпластин в цехе. Разработана объектная модель компьютерно-сетевой системыуправления транспортом и обработкой партий.
/> 2.1 Введение в предметную область. Анализ работыцехов ОАО Ангстрем
В этомразделе производится анализ существующей системы управления производствомпартий ОАО Ангстрем.
/> 2.1.1 Особенности технологического циклапроизводства партий пластин
Охарактеризуемособенности технологического процесса производства партий. Предварительновведем понятия (изделия, партии, технологические маршруты, маршрутные листы),которые потребуются при описании производственного процесса.
 2.1.1.1 Изделия, партии, технологические маршруты,маршрутные листы
Изделие — полупроводниковая микросхема, выполняющая заданные разработчиком функции. Каждоеизделие характеризуется индивидуальным технологическим маршрутом, которыйзаранее прорабатывается.
Партия — группа пластин, помещенных в специальный контейнер, имеющая номер исобственный маршрутный лист. Партия в полупроводниковом производствеобрабатывается и транспортируется в соответствии маршрутным листом. Всемножество партий можно разбить на группы по принадлежности к определенномуизделию (Рис.4). Принадлежность партии к определенному изделию находит отражениев номере. Номер партии состоит из двух частей: первая часть — номер изделия,вторая — порядковый номер в пределах данного изделия.
Технологическиймаршрут — последовательность операций, при выполнении которой наповерхности кремниевой пластины формируется заданная структура. Каждое изделиехарактеризуется индивидуальным технологическим маршрутом. Прохождение партии помаршруту отслеживается в настоящей системе управления с помощью маршрутноголиста.
Маршрутныйлист — документ, неразрывно связанный с партией. Маршрутный листпредставляет собой таблицу со следующими атрибутами: номер операции, названиеоперации, время поступления партии на участок, параметры режима обработки. Намаршрутном листе, закрепляемом за партией, ставится номер партии. Каждой партиисоответствует свой маршрутный лист, который прикреплен к коробке с пластинами. Напротяжении всего периода существования партии маршрутный лист следует за ней. Внем регистрируется прохождение партии по технологическому маршруту. Какправило, маршрутные листы тиражируются типографским методом.
Каждомуизделию ставится в соответствие индивидуальный технологический маршрут. Впределах одного изделия все партии имеют одинаковый маршрутный лист. Элементарнаяединица управления — партия, т.е. система управления отслеживает прохождениекаждой партии по маршруту. Партий, представляющих конкретное изделие (изготавливаемыхпо данному маршруту), может быть много (до 500). Номер партии пластинсоставляется из номера изделия и номера партии в пределах изделия (рис.4).
/> />
Рис.4. Схема нумерации партий
 2.1.1.2 Регистрация процесса производства партийпластин
Процесспроизводства партий контролируется посредством регистрации потоков партий врегистрационных журналах, в бланках незавершенного производства и в маршрутныхлистах. Регистрация необходима для контроля прохождения партий, в частности,при необходимости партию можно быстро найти.
Каждыйучасток имеет свой регистрационный журнал. В нем персонал установок отмечаетпартии, обработанные на данном участке. По нему считают проработку партий засмену, за месяц.
Для«нулевых» партий (запускаемых на начало обработки на входе цеха 201) естьсвой регистрационный журнал. Для полностью обработанных партий (на выходе цеха201) также есть отдельный регистрационный журнал.
Маршрутныйлист — документ, неразрывно связанный с партией. Каждой партии соответствуетсвой маршрутный лист, который прикреплен к коробке с пластинами. На протяжениивсего периода существования партии маршрутный лист следует за ней. Онпредставляет собой таблицу, содержащую: номер операции, название, времяпоступления партии, параметры режима обработки, колонку для росписи илитабельного номера.
Записи вмаршрутные листы вносят операторы участков. Операторы регистрируют выполнениетехнологических операций: по окончании обработки партии на конкретной операцииоператор ставит свой табельный номер и параметры режима обработки. Ни распреды,ни диспетчер, ни начальник смены не вносят никаких записей в маршрутный лист.
Бумажный«документооборот» (регистрация в журналах, бланках незавершенногопроизводства и маршрутных листах) до определенной степени избыточен, чтообеспечивает надежность контроля производственного процесса.
 2.1.1.3 Незавершенное производство
Важноепонятие, характеризующее производственный процесс — незавершенное производство(НЗП).
Незавершенноепроизводство — это продукция (партии кремниевых пластин), не прошедшая до концавесь технологический цикл.
УчитываетсяНЗП в регистрационных журналах, бланках незавершенного производства и вмаршрутных листах. В настоящее время незавершенное производство велико — количество партий НЗП в 4 раза превышает месячную пропускную способность цеха. Наличиебольшого НЗП приводит к тому, что растет длительность производственного цикла.
Большаявеличина НЗП связана с тем, что административный персонал цеха и завода, желаяувеличить загрузку оборудования, вводит в производственный процесс все новые иновые партии. При этом уже обрабатываемые партии скапливаются в «узкихместах» производственного процесса, что создает «рецидивы» накопленияНЗП.
/>/>2.1.2 Общая схема управления
/>

Рис.5. Общаясхема управления
/> 2.1.3 Задержки в транспорте и обработке партийпластин
В данноевремя существует много задержек в транспорте и обработке партий. Эти задержкиможно разделить на следующие группы:
обеденныеперерывы.
совещанияадминистративного персонала цеха.
сдача иприемка смен.
оформлениемсписка, где какие партии находятся, и поиск партий.
сбоиоборудования.
необходимостьпринимать повторные решения при сбое оборудования.
и т.п.
Первыетри группы задержек можно устранить посредством целенаправленной организациирабочего дня персонала (см. ниже).
Остальныегруппы задержек являются следствием несовершенства системы управления иконтроля. Контролировать их людьми очень трудно, поэтому вводится избыточнаязагрузка цеха партиями, чтобы обеспечить работой все участки в случае сбоев некоторых.Эта загрузка приводит к большому НЗП, что в свою очередь увеличиваетдлительность цикла. Автоматизированная система управления производственнымпроцессом призвана сократить эти задержки. Электронная система позволитповысить четкость отслеживания партий и планирования работ, в результате этогоможно будет уменьшить НЗП, не опасаясь перерывов в работе участков. УменьшениеНЗП в свою очередь приведет к уменьшению длительности производственного цикла.
Оценимколичественно задержки в транспорте партий и задержки в управлении транспортоми производством партий.
Задержкив транспорте партий, обусловленные неоптимальностью работы распредов (в расчетена сутки). Пересменка — 2*20 минут = 40 минут, обеденные перерывы 30*4 = 2 часа.Составление списка партий, поиск партий (полагаем пока условно, в дальнейшемэти цифры можно будет уточнить) — 2 часа в сутки.
Итого: задержкив транспорте партий составляют примерно 5 часов в сутки.
Устранитьэти задержки в электронной системе управления можно следующим образом (дляопределенности рассматриваем пример подцеха 131): Задержки, связанные спересменками и обеденными перерывами, можно устранить, вводя дополнительноодного распреда и вводя скользящий график работы. А именно, считаем, что первыйраспред начинает работу в 7-00, второй — в 7-30, третий — в 8-00. Сменапервого, второго и третьего распредов заканчивается в 19-00, 19-30 и 20-00соответственно. Аналогично смещаются относительно друг друга и обеденныеперерывы распредов. В результате, в подцехе все время будут находиться, покрайней мере, два распреда.
Задержки,связанные с составлением списков должны устраниться в электронной системеавтоматически, так как ведется учет всех партий. Составление списка (если этопотребуется будет сводиться к распечатке соответствующего документа).
Оценимзадержки в управлении (в сутки): совещания административного персонала цеха — 2*30 мин = 1 час, обеденные перерывы — 4*30мин =2 часа, сдача и приемка смен (полагаемпока условно, в дальнейшем эти цифры можно будет уточнить) — 2*30 мин = 1 час,сбои оборудования, необходимость принимать повторные решения при сбоеоборудования и т.п. (полагаем пока условно, в дальнейшем эти цифры можно будетуточнить) = 1 час.
Итого — 5часов в сутки не принимается решение о транспорте партий и обработке партий.
Этизадержки можно устранить следующим образом. Сократить или заменить краткойэлектронной конференцией (или телеконференцией) совещания административногоперсонала цеха. В крайнем случае, вынести эти совещания за рамки смены, т.е. проводитьсовещания не во время своей смены, а течение последних 30 минут предыдущейсмены. Обеденные перерывы распределить между административным персоналом, такчтобы не было перерывов в управлении транспортом партий.
Наличиеэлектронной системы позволит обеспечить указанное устранение задержек, так какбольшинство решений о транспорте партий будет приниматься именно электроннойсистемой и нагрузка на административный персонал радикально снизится. Сокращение(или даже полное устранение совещаний) будет возможно, так как многие вопросымогут быть сняты точным контролем и обеспечением информации на рабочие местаадминистративного персонала через терминалы компьютерно-сетевой системыуправления.
Электроннаясистема обеспечит более строгий учет за транспортировкой и обработкой партий. Приэтом снимаются проблемы поиска потерявшихся партий, необходимости принятияповторных решений. Система позволит оперативно и гибко реагировать на сбоиоборудования, меняя очередность прохождения партий на «узких» участках.
Крометого, система позволит собирать точную статистику по обработке партий,пропускной способности участков, дефектности; появится возможностьпрогнозирования, как на краткосрочную, так и на долгосрочную перспективу.
/> 2.2 Анализ требований к системе
Современноемикроэлектронное производство представляет собой сложный процесс. На уровнеотдельного цеха этот процесс включает в себя обработку партий полупроводниковыхпластин на установках, которые расположены на различных участках. Необходиматранспортировка партий между участками, необходим учет времен обработки партийна установках, возможных временных задержек обработки партий. Важно учестьприоритеты изготовления партий. Необходим контроль качества партий, исправлениедефектов обработки партий, учет возможных выходов из строя установок,обрабатывающих партии.
В этомпроцессе важно также найти компромисс между максимальной загруженностьюустановок цеха и минимальным циклом изготовления партий. Влияние загруженностиустановок на длительность цикла изготовления сводится к следующему: дляувеличения загрузки установок нужно запускать в производственный процесс какможно большее число партий, но при этом партии будут скапливаться в «узкихместах», в результате чего возникают большие очереди на установках, идлительность цикла изготовления отдельной партии будет возрастать.
Помимоэтого, необходимо осуществлять мониторинг качества работы участков, собирать иобрабатывать статистику о процессе производства партий.
Итак,необходима система управления производством партий. Эта система должнаобеспечивать принятие решений о транспорте и обработке партий. При этомколичество принимаемых решений в единицу времени достаточно велико: оценки длятипичного цеха дают величины порядка 108 элементарных принятийрешений в месяц. Следовательно, система управления должна быть оперативной. Болеетого, эта система должна быть достаточно «интеллектуальной», с тем,чтобы учесть указанные выше требования. Оперативность и «интеллектуальность»системы управления подразумевают, что она должна базироваться на современныхкомпьютерно-сетевых технологиях и использовать «интеллектуальные» схемыпринятия решения.
Внастоящем сообщении предлагаются принципы построения автоматизированнойкомпьютерно-сетевой системы управления транспортом и обработкой партийотдельного цеха.
Приразработке этих принципов мы основывались на общих методах и подходах,предложенных в системах ситуационного управления [1-4], и использовали идеиактивно развивающегося сейчас за рубежом направлений Manufacturing executingsystems (MES-системы) и Системы диспетчерского управления и сбора данных (SCADA-системы).
Общиетребования к автоматизированной системе управления производственным процессомсостоят в следующем. АСУ ПП должна:
Осуществлятьконтроль прохождения партий по технологическому маршруту.
Оптимизироватьпрохождение партий по различным маршрутам, чтобы все они обрабатывались в срок,с наилучшим выходом годных, и предприятие работало с наибольшей производительностью.
Собиратьи обрабатывать статистику о качестве работы участков, принимаемых решениях и ихрезультатах, и на основании этого изменять свое поведение и информироватьруководство о возможных причинах неоптимальной работы предприятия.
В рамкахподготовительного этапа была проведена следующая работа:
Проведенанализ принципов построения аналогичных систем управления (результаты анализаотражены в обзоре литературы).
Проанализированаструктура технологического процесса на ОАО «Ангстрем», сложившаяся кнастоящему времени.
Предложенаархитектура компьютерно-сетевой АСУ ПП, предназначенной для управлениятехнологическим процессом производства партий.
Произведенобъектно-ориентированный анализ технологического процесса производства партий. Врезультате анализа разработана объектная модель производственного процесса. Объектнаямодель представляет собой концептуальную основу разрабатываемойкомпьютерно-сетевой системы управления производством партий (см. технологическуючасть).
/> 2.3 Рекомендации к разработке автоматизированнойсистемы управления производственным процессом
На основепроведенного анализа можно рекомендовать следующие общие принципы построенияразработки автоматизированной системы управления производством партий (АСУ ПП) ОАО«Ангстрем».
Системауправления должна включать в себя:
Реляционнуюбазу данных для хранения всей информации о производственном процессе. Базаданных нужна для того, чтобы информация о состоянии производства былапредставлена в некотором стандартном формате.
Центральнуюпрограмму управления. Эта программа должна быть предназначена для:
Принятиярешений о транспорте и обработке партий.
Отслеживанияи сокращения задержек с целью сокращения производственного цикла.
Сборастатистики (пропускная способность участков, средний объем НЗП, задержки).
Контролированияобъема НЗП.
Формированияочереди к потенциально узким участкам.
Своевременногопредупреждения «рецидивов» накопления НЗП.
Планированияна краткосрочную и долгосрочную перспективу.
Предполагается,что эта программа управления должна быть расположена на центральном компьютереи помогать принимать решения диспетчеру и персоналу участков.
Локальныетерминалы на участках, предназначенные для обмена информацией между персоналомучастков и центральным компьютером.
Имитационнуюпрограмму, предназначенную для анализа производственного процесса и поискаоптимальных режимов управления производством. Системы регистрации и мониторингапроизводства партий.
Общениепрограммного обеспечения с пользователями должно происходить посредством максимальноудобного и интуитивно понятного интерфейса, например, типа MSWindows. Анализ развития компьютерных технологий и опыта зарубежных фирм поразработке MES — и SCADA-систем показывает, что АСУ ППдолжна базироваться на компьютерно-сетевых технологиях и использовать методыобъектно-ориентированного программирования./> 2.4 Предлагаемая архитектура автоматизированнойсистемы управления производственным процессом
В этомразделе кратко излагаются предложения по созданию системы управленияпроизводством партий.
/> 2.4.1 Общая схема управления
Общаясхема системы управления представлена на Рис.6. Система предназначена дляуправления производством партий в отдельном цехе.
/>

Рис.6. Архитектурасистемы управления производством партий в цехе
Стрелкамипоказаны информационные потоки. Двойными стрелками показаны информационныепотоки между программными модулями в центральном блоке управления. Блоки «Тренинг»и «Имитационная модель» не входят в систему управления цехом, а тольколишь связаны с ней.
Блокисистемы управления описаны ниже.
Группаконтроля осуществляет общее руководство управлением производством партий вцехе. В группу контроля входит диспетчер и, возможно, другой административныйперсонал. Группа контроля интерактивно взаимодействует с программой управленияпроизводством. Программа осуществляет управление потоками партий в режиме«автопилота». Группа контроля имеет право вмешиваться в режимуправления. В случае необходимости группа контроля принимает управление на себяи выполняет управление «в ручном режиме».
Программауправления производством предназначена для управления потоками партий врежиме реального времени. Эта программа отслеживает весь производственныйпроцесс.
Предварительно,модули и функции программы управления можно описать следующим образом:
Программадолжна содержать модуль принятия решения, который обеспечивает решения отранспорте партий и загрузке установок.
Программадолжна содержать модуль контроля участков. Этот модульотслеживает соответствие между инструкциями программы управления и работойучастков.
Программаотслеживает весь процесс производства вплоть до конкретного исполнителя.
В реляционнойбазе данных собирается информация о процессе производства партий. Этаинформация используется как в программе управления производством, так и вимитационной модели.
Имитационнаямодель предназначена для исследования функционирования и оптимизации самойсистемы управления.
Предполагается,что разработанная программа (или ее упрощенная версия) будет использоваться длятренинга персонала. Для отдельных цехов блоки «Имитационная модель»и «Тренинг» могут отсутствовать.
/>/>2.4.2 Взаимодействие программы регистрации и персонала
Персоналучастка выполняет операции в соответствии с инструкциями программы и ставитв известность программу о выполненных операциях. Программа регистрации процессапроизводстваставит обработанную партию в очередь на все установки,соответствующие дальнейшему маршруту партии. Приоритеты рассчитываются только вслучае конфликтов. При расстановке приоритетов учитываются мощности установок (скажем,партия с большим приоритетом должна обрабатываться на более мощной установке). Программеизвестно нормативное время обработки партии, и если потери времени существенны,то информация об этом поступает в группу контроля.
На каждомучастке есть терминал, через который осуществляется взаимодействие междупрограммой и персоналом участка.
Предполагается,что регистрация выполнения операций осуществляется с помощью внесенияоператором участка информации в базу данных.
Как и вимеющейся системе, транспорт партий осуществляется распредами, а анализзабракованных партий — ведущим технологом.
/> 2.4.3 Реализация
Предлагаетсяследующая схема технической реализации (схема может быть уточнена в процесседальнейшей работы). Программа управления производством реализуется нацентральной ЭВМ. Реляционная база данных и имитационная модель реализуются наотдельном сервере либо на центральной ЭВМ. На участках с длительнымитехнологическими операциями есть терминал, который обеспечивает информационноесообщение между персоналом участка и программой управления производством. Рабочиеместа диспетчера и ведущего технолога также оснащаются терминалами.
/>/>2.4.4 Управление обработкой партий/> 2.4 4.1 Понятие дисциплины очереди
Управлениетранспортом партий происходит в соответствии с определенной дисциплиной очереди.
Дисциплинаочереди — это набор правил, в соответствии с которыми осуществляется управлениепорядком обработки партий на установках.
Существуетдва типа очередей:
ОчередиНЗП, таких очередей несколько, отдельная конкретная очередь соответствуетопределенной установке. Партии, стоящие в этих очередях, «ждут» подачина начало соответствующего микроцикла.
Очередьна установках, партии в этих очередях «ждут» подачи на операциювнутри микроцикла.
Ожиданиев очереди 1-го типа может быть длительным (часы, сутки, недели). Ожидание вочереди 2-го типа должно быть кратковременным (минуты, десятки минут).
Управлениеочередями 2-го типа простое, оно осуществляется по методу FIFO (первым пришел — первым вышел), т.е. в первую очередь обрабатываются те партии, которые первымипопали в очередь.
Основноеуправление осуществляется между микроциклами. Это управление осуществляетгруппа контроля при помощи программы управления производством. Эта группаанализирует загруженность цеха, и определяет момент, когда способен принятьпартию из НЗП на обработку. Именно здесь важно использовать продуманнуюдисциплину очереди.
Нижеприведены схемы дисциплины очереди. 2.4.4.2 Предварительная схема дисциплины очереди
Приформировании дисциплины очереди необходимы знания об определенных параметрахпартии и производственного процесса. Выделим эти параметры.
Основныепараметры (атрибуты партий, атрибуты установок, характеристикипроизводственного процесса), которые требуется учесть при управлении потокамипартий:
Времязадержки прохождения партией данной операции (отрицательные времена тоже важны),Δ tзад;
Априорнаяважность партии, Imp (обычная партия Imp = 1, важная партия Imp= 2,3,…) априорную важность партии устанавливает группа контроля по заданиюруководства;
Процентпрохождения маршрута, Pr;
Прогнозследствий невыполнения;
Коэффициентнагрузки, r = Iзаявок / Iобслуживания (I — интенсивность). r зависит от НЗП. Средняя длина очереди зависит от r:l = [1 — r] -1 Разумно выбирать r ≤ 0,5 — 0,6, в этом случае длина очереди l = ≤ 2 — 2,5.
Предварительнаясхема управления потоками партий такова.
Еслипартия прошла n-й микроцикл, то в программу управления производствомпоступает рапорт о выполнении микроцикла и заявка на выполнение n +1-огомикроцикла.
Считаем,что схема имеет вид правил:
Если ….,то …., иначе.
Некоторыеиз правил требуют выполнения определенных расчетов. Схема принятия решенияоснована на учете указанных выше параметров.
Опишемконкретный вариант упрощенной схемы принятия решения.
Еслиесть свободная установка для выполнения первой операции n +1-огомикроцикла, и эта установка одна, то заявка подается на эту установку.
Иначе
Еслисвободных устройств несколько, то заявка подается на установку снаибольшим приоритетом для данной партии.
Иначе
Есливсе устройства, соответствующие первой операции n +1-ого микроциклазаняты,то партия подается в очередь на все эти установки.
Привозникновении свободного устройства обрабатывается партия с наибольшим текущимприоритетом.
Впростейшем случае текущий приоритет есть Δ tзад * Imp.
Еще разподчеркнем, что необходим отдельный анализ по разработке дисциплины очереди. Отметим,что известен ряд методов формирования систем управления, подобныхразрабатываемой системе. Одна из серьезных проработок: методы ситуационногоуправления, описанные выше. Второй пример — схемы классифицирующих систем (ClassifierSystems), представляющие собой самообучающиеся системы принятия решения. Этисистемы основаны на использовании правил типа «Если …., то …. ». Совокупностьтаких правил оптимизируется как путем обучения (переоценка приоритетов правил),так и путем эволюции (эволюционный поиск новых правил). Еще одну возможностьпредоставляют системы поддержки принятия решений, основанные на активноприменяемом в последнее время нейросетевом подходе./>2.5 Техническое заданиена дипломный проект
Исходя изизложенного выше материала, сформулируем техническое задание на дипломноепроектирование.
Необходиморазработать программу регистрации процеса производства партий полупроводниковыхпластин для использования в автоматизированной системе управления.
Программадолжна обеспечивать контроль и регистрацию производственного процессапроизводства партий пластин. Вести учет за прохождением партийполупроводниковых пластин по технологическому маршруту. Разработку провести,используя объектно-ориентированный подход.
К программерегистрации предъявляются следующие требования:
Регистрироватьпередачу партии полупроводниковых пластин на участок.
Фиксироватьвремя начала и окончания выполнения технологической операции.
Осуществлятьуправление очередностью изготовления партий на установках с длительнымиоперациями.
Формироватьплановый срок для каждой операции обработки и следить за его соблюдением.
Оцениватьпотери, с их разложением на каждом участке для каждой смены.
Программадолжен функционировать в среде MS Windows 95,98,NT. Предполагаетсяиспользовать программу на участках с длительными технологическими операциями (нанесениеэпитаксиальных структур, диффузия, металлизация)./>/>2.6 Выбор платформы и инструмента разработки программы
Вкачестве операционной системы для реализации программного обеспечения былавыбрана среда Windows’98 (Windows NT). Можно выделить следующиепричины, обосновывающие этот выбор:
Распространенностьэтих операционных систем;
удобствографического интерфейса дает возможность при минимизации затрат на егореализацию максимизировать удобство работы оператора с программой. Интерфейсстандартизован, соответственно оператор не потратит много времени на освоениепрограммы и в дальнейшем количество возможных ошибок в его действиях будетминимизировано;
возможностьработы с большими массивами данных, реализация чего в среде Windows 3.1 или в среде MS-DOSпредставляет нетривиальную и трудновыполнимую задачу;
32-разрядностьсистем Windows’95 и Windows NT увеличивает скорость выполнениявычислительных задач.
Вкачестве среды программирования была выбрана среда Visual C++ фирмы MicroSoft,сочетающая в себе следующие преимущества:
простотаи надежность создания и отладки программы;
использованиевсех преимуществ операционных систем Windows’98 и Windows NT,включая 32-разрядность, многозадачность, удобный интерфейс и прочее;
использованиеобработки исключений (exceptions), что позволяетповысить надежность работы программного продукта;
наличие идоступность большого количества компонент, реализующих многие стандартныефункции;
наличиемощных, удобных утилит для отладки и тестирования программного обеспечения;
наличиебольшой системы справочной информации, руководств разработчика, облегчающейсоздание программного обеспечения.
/>3. Разработкаалгоритмов и программ
 3.1 Этапы объектно-ориентированного подхода
Ксозданию системы был выбран объектно-ориентированный подход. Этот подходпредусматривает спиральную модель создания информационных систем, котораясостоит из следующих этапов:
Анализтребований.
Проектирование.
Реализация(программирование).
Тестирование.
Спиральнаямодель подразумевает, что эти этапы циклически повторяются, на каждом цикле впрограмму вносятся исправления и новые возможности. Этот способ созданияпрограммного обеспечения позволяет достаточно быстро получить первую рабочуюверсию программы, а на следующих циклах реализовывать дополнительно возникающиетребования и оптимизировать существующие части программы, не нарушая еецелостности и работоспособности.
Объектно-ориентированныйанализ
Нижеприводятся результаты первого этапа — анализа требований к проектируемой системе.При анализе использовались стратегии и образцы, разработанные Питером Коудом, атакже методология OMT (Object Modeling Technique). Результатами анализаявляются назначение системы, характерные свойства, объектная модель.
Назначениесистемы:
Обеспечитьконтроль и регистрацию производственного процесса производства партий пластин. Вестиучет за прохождением партий полупроводниковых пластин, как материальныхценностей.
/>3.2 Характерныесвойства системы
Системадолжна:
Регистрироватьпередачу партии полупроводниковых пластин на участок.
Составлятьграфик изготовления для каждой партии и следить за его выполнением.
Фиксироватьрезультаты контроля и измерений для последующего анализа.
Фиксироватьвремя начала и окончания выполнения технологической операции.
Определятьочередность и времена запуска партий на обработку.
Осуществлятьуправление очередностью изготовления партий на установках с длительнымиоперациями.
Формироватьплановый срок для каждой операции обработки и следить за его соблюдением.
Оцениватьпотери, с их разложением на каждом участке для каждой смены.
 3.3 Выбранные объекты
Впроцессе анализа были выявлены следующие объекты:
Группаконтроля — лицо или группа лиц, осуществляющее планирование запуска партий изНЗП в производство и материально ответственное за партии, хранящиеся в НЗП.
Транспорт- служба, занимающаяся транспортировкой партий между участками.
Представительучастка — лицо или группа лиц, материально ответственное за партии находящиесяна участке.
Ведущийтехнолог — лицо, принимающее решения в случае забраковки партий на контроле.
Установка- устройство, осуществляющее операции над партиями.
Участок — административная единица, выполняющая некий набор операций над партиями.
УчастокНЗП — участок, на котором партии хранятся между микроциклами, в НЗП поступаютновые партии и готовые партии.
Шкаф — местона участке НЗП, в котором партии хранятся между микроциклами.
Контроль — 1) участок, на котором осуществляется операция контроля,
2) операцияконтроля, на которой выявляется брак.
Партия — объект,подвергающийся операциям на участках в соответствии с маршрутным листом.
Маршрутныйлист — документ, содержащий список операций, которые партия должна пройти впроцессе изготовления.
Операция- действие, изменяющее готовность партии, этап изготовления партии согласномаршрутному листу.
Хранение- операция, которой подвергаются партии между микроциклами.
Очередь — место на технологическом участке, где находятся партии в ожидании очереднойоперации.
Реставрация- изменение в технологическом маршруте, возникающее в связи с браком,осуществляется ведущим технологом.
Микроцикл- часть технологического маршрута; между микроциклами партия может хранитьсядлительное время.
Забраковка- признание партии непригодной для дальнейшей обработки, ее удаление из планапроизводства и, возможно, запуск новой идентичной партии.
Входнойсчитыватель штрихкода — устройство, фиксирующее поступление партии на участок.
Выходнойсчитыватель штрихкода — устройство, фиксирующее передачу партии с участка натранспорт.
Технологическийучасток — административная единица, выполняющая некий набор операций надпартиями на установках, составляющих данный участок.
Терминал- средство общения между системой управления и персоналом.
Цех — помещение,в котором осуществляется производство.
УчастокВТ — место нахождения Ведущего технолога.
/>
Рис.7. Объектнаямодель, характеризующая объекты системы управления и связи между ними
Объектнаямодель показывает планируемую структуру программы, с точки зренияобъектно-ориентированного подхода. В этой модели показаны объекты, важные дляпроектируемой системы и связи между ними. Рис.8 поясняет нотацию (системуобозначений) Unified, в которой приведена модель./> />
Рис.8. Обозначения, принятые в объектной модели
Впроцессе проектирования и разработки программы управления к модели будутдобавляться новые объекты и связи, для объектов будут определяться атрибуты иметоды, взаимодействие между объектами будет описано через сценарии. Конечнымрезультатом усложнения модели будет программа управления производством. Всеобъекты, приведенные в данной модели, будут являться частями будущей программы.
 3.4 Алгоритм выполнения технологической операции
В даннойпрограмме схема работы представлена двумя основными алгоритмами. Рис.9описывает алгоритм выполнения технологической операции.

/>
Рис.9. Алгоритмвыполнения технологической операции
/>3.5 Алгоритмформирования дисциплины очереди
Рис.10конкретизирует этап выбора партии полупроводниковых пластин для обработки.
Управлениетранспортом партий происходит в соответствии с определенной дисциплиной очереди.
Дисциплинаочереди — это набор правил, в соответствии с которыми осуществляется управлениепорядком обработки партий на установках.
Проведенныйанализ выявил 4 правила, в соответствии с которыми из всего множества партийпластин выбирается одна для обработки. Правила перечислены в порядке убыванияприоритета. Каждое последующее правило применяется, когда выполнены всепредыдущие.
Выбратьиз всего множества партии с минимальным межоперационным временем;
Выбратьиз оставшегося списка партии пластин с высоким априорным приоритетом;
Выбратьиз оставшегося списка партии, близкие к завершению технологического цикла;
Использоватьправило «FIFO — первым вошел — первым вышел».
Всерассмотренные правила представлены алгоритмом.

Рис.10. Алгоритмформирования дисциплины очереди
/>3.6 Использование библиотекиMicrosoft Foundation Classes
Приразработке программы использовались преимущества библиотеки классов MFC, предоставляющей программисту набор мощных инструментов. Библиотекаинкапсулирует наиболее важные структуры и функции интерфейса прикладногопрограммирования в группе классов, пригодных для многократного использования.
Использованиеобъектно-ориентированного подхода дает многочисленные преимущества в сравнениис традиционным стилем программирования:
Инкапсуляциякода и данных внутри класса;
Наследование;
Разрешениеколлизий имен функций;
Уменьшаетсяобщий объем текстов.
Основныевозможности библиотеки MFC:
Поддержкавсех функций, управляющих элементов и ссобщений Windows,графических примитивов GDI, меню и окон диалога;
Использованиесоглашения об именах API Windows, при котором по имени класса становится ясным егопредназначение;
Избавлениеот необходимости применять оператор switch/case, который часто является источником ошибок. Каждомусообщению ставится в соответствие функция-член класса;
Архитектура,основанная на широком использовании обработки исключительных ситуаций, делаеткод приложения более устойчивым к ошибкам.
На рис.11приведена иерархия классов программы. Ниже будут приведены пояснения дляосновных классов.

Рис.11. Иерархияклассов программы регистрации процесса производства
/>

Cobject — базовый класс, широко используемый при разработкеприложений Windows.
CCmdTarget -
CWnd — родительский класс для всех окон.
CWinApp — родительский класс для приложения.
CDialog — родительский класс для окон диалога.
Как видноиз иерархии классов, программа состоит из четырех основных классов:
CAngstremApp — основной класс. Разделен на два файла — заголовочнымдля него является файл cangstremapp. h,файл реализации — cangstrem. cpp.
CMainFrame — этот класс, производный от CFrameWnd,используется для управления главным окном приложения.
CAngstremView — является наследником класса CView.Класс CView, производный от CWnd,служит базовым для пользовательских классов отображения. Отображение (view) служит промежуточным звеном между документом ипользователем. Обычно отображение — это дочернее окно главного окна.
CAngstremDoc — класс используется для хранения данных.
Технологическая часть:
/>Технология разработкипрограммных систем
Выполнил:
Ляшко М.А.
Консультант:
БрусникинГ.Н.
/>/>4. Объектно-ориентированное программирование 4.1 Введение
В основеразработки программного обеспечения, как и любой отрасли промышленногопроизводства, лежит технологический процесс. Качество программного продукта,его стоимость, сроки создания определяются тем, насколько хороша принятая нафирме технология разработки программ и насколько точно она соблюдается. Этоутверждение, очевидное для всех отраслей промышленности еще со времен цеховыхмастеров, не легко пробивает себе дорогу в мир разработки программного обеспечения.Это связано с тем, что программирование — это интеллектуальныйвысокотехнологичный труд, очень тяжело поддающийся формализации. Но законыразвития промышленного производства одинаковы для всех отраслей промышленности.
Технологияпрограммирования — это совокупность методов и средств разработки (написания) программи порядок применения этих методов и средств. На ранних этапах развитияпрограммирования, когда программы писались в виде последовательностей машинныхкоманд, какая-либо технология программирования отсутствовала. Первые шаги вразработке технологии состояли в представлении программы в видепоследовательности операторов. Написанию последовательности машинных командпредшествовало составление операторной схемы, отражающей последовательностьоператоров и переходы между ними. Операторный подход позволил разработатьпервые программы для автоматизации составления программ — так называемыесоставляющие программы.
Сувеличением размеров программ стали выделять их обособленные части и оформлятьих как подпрограммы. Часть таких подпрограмм объединялась в библиотеки, изкоторых подпрограммы можно было включать в рабочие программы и затем вызыватьиз рабочих программ. Это положило начало процедурному программированию — большаяпрограмма представлялась совокупностью процедур-подпрограмм. Одна изподпрограмм являлась главной и с нее начиналось выполнение программы.
В 1958году были разработаны первые языки программирования, Фортран и Алгол-58. Программана Фортране состояла из главной программы и некоторого количества процедур — подпрограмми функций. Программа на Алголе-58 и его последующей версии Алголе-60представляла собой единое целое, но имела блочную структуру, включающую главныйблок и вложенные блоки подпрограмм и функций. Компиляторы для Фортранаобеспечивали раздельную трансляцию процедур и последующее их объединение врабочую программу, первые компиляторы для Алгола предполагали, чтотранслируется сразу вся программа, раздельная трансляция процедур необеспечивалась.
Процедурныйподход потребовал структурирования будущей программы, разделения ее наотдельные процедуры. При разработке отдельной процедуры о других процедурахтребовалось знать только их назначение и способ вызова. Появилась возможностьперерабатывать отдельные процедуры, не затрагивая остальной части программы,сокращая при этом затраты труда и машинного времени на разработку имодернизацию программ.
Следующимшагом в углублении структурирования программ стало так называемое структурноепрограммирование, при котором программа в целом и отдельные процедурырассматривались как последовательности канонических структур: линейныхучастков, циклов и разветвлений. Появилась возможность читать и проверятьпрограмму как последовательный текст, что повысило производительность трудапрограммистов при разработке и отладке программ. С целью повышенияструктурности программы были выдвинуты требования к большей независимостиподпрограмм, подпрограммы должны связываться с вызывающими их программамитолько путем передачи им аргументов, использование в подпрограммах переменных,принадлежащих другим процедурам или главной программе, стало считатьсянежелательным.
Процедурноеи структурное программирование затронули прежде всего процесс описанияалгоритма как последовательности шагов, ведущих от варьируемых исходных данныхк искомому результату. Для решения специальных задач стали разрабатыватьсяязыки программирования, ориентированные на конкретный класс задач: на системыуправления базами данных, имитационное моделирование и т.д.
Далеесовершенствование аппаратных средств и многократное усложнение программногообеспечения обусловило появление так называемого объектно-ориентированногопрограммирования, ставшего действительно гигантским шагом вперед в развитиивсего программирования в целом. В этой главе будет рассматривается весь этапсоздания программного продукта от постановки задачи и анализа до его внедренияи сопровождения с применением именно объектно-ориентированных технологий. Однако,опыт программирования показывает, что любой методологический подход втехнологии программирования не должен применяться слепо с игнорированием другихподходов. Это относится и к объектно-ориентированному подходу./>/>/>4.2 Понятие жизненного циклапрограммного обеспечения
Одним избазовых понятий методологии разработки информационных систем является понятиежизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО — это непрерывныйпроцесс, который начинается с момента принятия решения о необходимости созданияпрограммного обеспечения и заканчивается в момент его полного изъятия изэксплуатации.
Основнымнормативным документом, регламентирующим ЖЦ ПО, является международный стандартISO/IEC 12207 (ISO — International Organization of Standardization).Он определяет структуру жизненного цикла, содержащую процессы, действия изадачи, которые должны быть выполнены.
/>/> 4.3 Модели жизненного цикла программногообеспечения
Стандарт ISO/IEC 12207 не предлагаетконкретную модель жизненного цикла и методы разработки ПО. Его регламентыявляются общими для любых моделей ЖЦ, методологий и технологий его разработки.
Подмоделью ЖЦ понимается структура, определяющая последовательность выполнения ивзаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит отспецифики разрабатываемой информационной системы и специфики условий, в которыхсистема создается и функционирует. К настоящему моменту наибольшеераспространение получили следующие две основные модели ЖЦ: каскадная модель испиральная модель.
Визначально существовавших однородных ИС приложения представляли собой единоецелое. Для разработки такого типа приложений применялся каскадный способ. Егоосновной характеристикой является разбиение всей разработки на этапы, причемпереход с одного этапа на другой происходит только после того, как будетполностью завершена работа на текущем (рис.12).
Каждыйэтап завершается выпуском полного комплекта документации, достаточной для того,чтобы разработка могла быть продолжена другой командой разработчиков.

/>
Рис.12. Каскаднаясхема разработки программного обеспечения
Преимуществаприменения каскадного способа заключается в следующем:
На каждомэтапе формируется законченный набор проектной документации, отвечающейкритериям полноты и согласованности;
выполняемыев логичной последовательности этапы работ позволяют планировать срокизавершения всех работ и соответствующие затраты;
каскадныйподход хорошо зарекомендовал себя при построении информационных систем, длякоторых в самом начале можно достаточно точно и полно сформулировать всетребования, с тем чтобы предоставить разработчикам свободу реализовать ихтехнически как можно лучше. В эту категорию попадают сложные расчетные системы,системы реального времени и др.
В то жевремя этот подход обладает рядом существенных недостатков, вызванных преждевсего тем, что реальный процесс создания достаточно сложного ПО никогдаполностью не удавалось уложить в такую жесткую схему, постоянно возникалапотребность в возврате к предыдущим этапам и уточнении или пересмотре ранеепринятых решений. В результате реальный процесс создания ПО принимал вид,представленный на рис.13. Вторым недостатком каскадного подхода являетсясущественное запаздывание с получением результатов. Согласование результатов спользователями производится только в точках, планируемых после завершениякаждого этапа работ, требования к информационной системе “заморожены" ввиде технического задания на все время ее создания. Таким образом, пользователимогут внести свои замечания только после того, как работа над системой будетполностью завершена.
/>
Рис.13. Схемареального процесса разработки программного обеспечения
Для преодолениявышеперечисленных проблем была предложена спиральная модель ЖЦ, в которойделается упор на начальные этапы ЖЦ: анализ и проектирование с использованиемобъектно-ориентированного подхода. На этих этапах реализуемость техническихрешений проверяется путем создания прототипов. Каждый виток спиралисоответствует созданию фрагмента или версии ПО, на нем уточняются цели ихарактеристики проекта, определяется его качество и планируются работыследующего витка спирали. Таким образом, постепенно углубляются ипоследовательно конкретизируются детали проекта. Основная проблема спиральногоцикла — определение момента перехода на следующий этап. Для ее решениянеобходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переходосуществляется в соответствии с планом, даже если вся запланированная работа незакончена.
/>
Рис.14. Спиральнаямодель жизненного цикла
/>/> 4.4 Анализ
Первыйшаг в разработке прикладной информационной системы заключается в точномформулировании целей внедрения машинной обработки. Требования к системе еще несоздают полной картины. В постановке задачи, разумеется, должны принять участиекак представители организации-заказчика, так и те, кто будет заниматьсяпроектированием системы. Необходимо, чтобы этот процесс был гибко организован ипродолжался в течении достаточно длительного времени, поскольку на любом этаперазработки или внедрения могут вскрываться ранее не предусмотренные трудности,требующие внесения определенных изменений в проект. В то же время с цельюупрощения разработки в договор следует включить пункт, который запрещал бырадикальный пересмотр требований, на стадии реализации системы. В этом жепункте могут быть оговорены условия внесения несущественных изменений. Вседоговоренности должны оформляться в официальном порядке.
Разработкаинформационной системы на базе ЭВМ, включает такой обязательный элемент, какопределение формы, в которой должна быть представлена информация, хранящаяся вхранилище. Кроме того, необходимо установить какие варианты данных будутиспользоваться на различных этапах, начиная от сбора исходной информации изаканчивая выдачей результатов. Очевидно, формы, применяемые на этапах сбораданных, их корректировки или выборки с целью проведения той или иной обработки,могут отличаться друг от друга. Варианты данных должны охватывать все входящиев автоматизированную систему и исходящие из нее информационные потоки. Постановказадачи должна охватывать весь процесс сбора, хранения, использования иокончательного представления данных. В ней должны также учитываться ограниченияна время обработки, финансовые затраты и вычислительные ресурсы. Кроме того, впостановке задачи следует предусмотреть возможность последующей модернизациисистемы. Оценка будущих потребностей должна осуществляться совместно какпроектировщиками системы, так и ее потенциальными пользователями, посколькунеобходимо принимать компромиссные решения, касающиеся соотношения междууниверсальностью и эффективностью, гибкостью организации данных и стремлениемобеспечить текущие потребности.
/>/> 4.5 Проектирование
Этаппроектирования в разработке информационной системы представляет собой наиболееответственный процесс. Результат этого этапа накладывает самый большойотпечаток на всю систему. И грамотное проведение этого процесса в последствиенамного облегчит труд разработчиков на следующих этапах. Поэтому наиболееподробно рассмотрим этот этап в разработке программного обеспеченияинформационной системы.
В любойинженерной дисциплине под проектированием обычно понимается некийунифицированный подход, с помощью которого мы ищем пути решения определеннойпроблемы, обеспечивая выполнение поставленной задачи. В контексте инженерногопроектирования цели проектирования определяются как создание системы, которая:
удовлетворяетзаданным (возможно, неформальным) функциональным спецификациям;
согласованас ограничениями, накладываемыми оборудованием;
удовлетворяетявным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению;
удовлетворяетявным и неявным критериям дизайна продукта;
удовлетворяеттребованиям к самому процессу разработки, таким, например, какпродолжительность и стоимость, а также привлечение дополнительныхинструментальных средств.
Попредположению Страуструпа: «Цель проектирования — выявление ясной иотносительно простой внутренней структуры, иногда называемой архитектурой… Проектесть окончательный продукт процесса проектирования». Проектированиеподразумевает учет противоречивых требований. Его продуктами являются модели,позволяющие нам понять структуру будущей системы, сбалансировать требования инаметить схему реализации.
/>/> 4.5.1 Методы проектирования
Ясно, чтоне существует такого универсального метода, который бы провелинженера-программиста по пути от требований к сложной информационной системе доих выполнения. Проектирование такой информационной системы отнюдь не сводится кслепому следованию некоему набору рецептов. Скорее это постепенный иитеративный процесс. И тем не менее использование методологии проектированиявносит в процесс разработки определенную организованность. Как уже утверждалосьвыше, инженеры-программисты с момента зарождения программирования до снастоящих дней разработали десятки различных методов, которые можноклассифицировать по трем категориям:
процедурноепрограммирование;
методструктурного проектирования «сверху вниз»;
методпотоков данных;
объектно-ориентированноепроектирование.
Структурноепроектирование «сверху вниз» основано на алгоритмической декомпозиции.При таком подходе к проектированию происходит обычное разделение алгоритмов,где каждый модуль системы выполняет один из этапов общего процесса. Структурныйподход в проектировании в течение большого промежутка времени был практическилидером среди имеющихся методов разработки программного обеспечения. Но в связис резким скачком развития аппаратного обеспечения, появлением очень мощныхвычислительных комплексов, и как результат — многократное усложнениепрограммного обеспечения, структурное проектирование перестало быть эффективным.Значение структурного подхода осталось прежним, но было замечено, чтоструктурный подход не работает, если объем программы превышает приблизительно100000 строк. Структурный подход не позволяет выделить абстракции и обеспечитьограничение доступа к данным; он также не предоставляет достаточных средств дляорганизации параллелизма. Структурный метод не может обеспечить созданиепредельно сложных систем, и он, как правило, неэффективен в объектных иобъектно-ориентированных языках программирования. Однако, в некоторых случаяхего применение в этих языках оправдывает себя.
В методепотоков программная система рассматривается как преобразователь входных потоковв выходные. Метод потоков данных, как и структурный метод, с успехом применялсяпри решении ряда сложных задач, в частности, в системах информационногообеспечения, где существуют прямые связи между входными и выходными потокамисистемы и где не требуется уделять особого внимания быстродействию. Болееподробно остановимся на третьем методе проектирования, т.к он на данный моментявляется самым современным и эффективным средством проектированияинформационных систем. Объектно-ориентированное проектирование — этометодология проектирования, соединяющая в себе процесс объектной декомпозиции иприемы представления логической и физической, а также статической идинамической моделей проектируемой системы.
В данномопределении содержатся две важные части: объектно-ориентированноепроектирование, во-первых основывается на объектно-ориентированнойдекомпозиции, во-вторых использует многообразие приемов представления моделей,отражающих логическую (классы и объекты) и физическую (модули и процессы) структурусистемы, а также ее статические и динамические аспекты.
Именнообъектно-ориентированная декомпозиция отличает объектно-ориентированноепроектирование от структурного; в первом случае логическая структура системыотражается абстракциями в виде классов и объектов, во втором — алгоритмами./>/>/>4.5.2 Объектно-ориентированнаямодель
Объектно-ориентированнаятехнология основывается на так называемой объектной модели. Основными еепринципами являются: абстрагирование, инкапсуляция, модульность, иерархичность,типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе ненов, но в объектной модели они впервые применены в совокупности.
Абстракциявыделяет существенные характеристики некоторого объекта, отличающие его от всехдругих видов объектов и, таким образом, четко определяет его концептуальныеграницы с точки зрения наблюдателя. Абстрагирование концентрирует внимание навнешних особенностях объекта и позволяет отделить самые существенныеособенности поведения от несущественных.
Инкапсуляция- это процесс отделения друг от друга элементов объекта, определяющих егоустройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактныеобязательства абстракции от их реализации.
Модульность- это свойство системы, которая была разложена на внутренне связные, но слабосвязанные между собой модули. Таким образом, принципы абстрагирования,инкапсуляции и модульности являются взаимодополняющими. Объект логическиопределяет границы определенной абстракции, а инкапсуляция и модульность делаютих физически незыблемыми.
Значительноеупрощение в понимании сложных задач достигается за счет образования изабстракций иерархической структуры. Таким образом иерархия — это упорядочениеабстракций, расположение их по уровням.
Типизацияявляется способом защиты от использования объектов одного класса вместодругого, или по крайней мере, управлять таким использованием. Типизациязаставляет выражать абстракции так, чтобы язык программирования, используемый вреализации, поддерживал соблюдение принятых проектных решений.
В товремя, как объектно-ориентированное программирование основано на абстракции,инкапсуляции и наследовании, параллелизм главное внимание уделяетабстрагированию и синхронизации процессов. Каждый объект (полученный наконкретном уровне абстракции) может представлять собой отдельный потокуправления (абстракцию процесса). Такой объект называется активным. Система,построенная на основе ООП, может быть представлена, как совокупностьвзаимодействующих объектов, часть из которых является активной и выступает вроли независимых вычислительных центров.
Любойпрограммный объект существует в памяти и живет во времени. Существуют объекты,которые присутствуют лишь во время вычисления выражения, но есть и такие, какбазы данных, которые существуют независимо от программы. Этот спектрсохраняемости объектов охватывает:
промежуточныерезультаты вычисления выражений;
локальныепеременные в вызове процедур;
собственныепеременные, глобальные переменные и динамически создаваемые данные;
данные,сохраняющиеся между сеансами выполнения программы;
данные,сохраняемые при переходе на новую версию программы;
данные,которые вообще переживают программу.
В использованииобъектно-ориентированной модели можно выделить следующие преимущества:
объектнаямодель позволяет в полной мере использовать выразительные возможности объектныхи объектно-ориентированных языков программирования.
Использованиеобъектного подхода существенно повышает уровень унификации разработки ипригодность для повторного использования не только программ, но и проектов, чтов конце концов ведет к созданию среды разработки. Объектно-ориентированныесистемы часто получаются более компактными, чем их не объектно-ориентированныеэквиваленты. А это означает не только уменьшение объема кода программ, но иудешевление проекта за счет использования предыдущих разработок, что даетвыигрыш в стоимости и времени.
Использованиеобъектной модели приводит к построению систем на основе стабильныхпромежуточных описаний, что упрощает процесс внесения изменений. Это даетсистеме возможность развиваться постепенно и не приводит к полной еепереработке даже в случае существенных изменений исходных требований.
Объектнаямодель уменьшает риск разработки сложных систем, прежде всего потому, чтопроцесс интеграции растягивается на все время разработки, а не превращается вединовременное событие. Объектный подход состоит из ряда хорошо продуманныхэтапов проектирования, что также уменьшает степень риска и повышает уверенностьв правильности принимаемых решений./>/>/>4.5.3 Процессобъектно-ориентированного проектирования
Процессобъектно-ориентированного проектирования не сводится к одностороннему движению«сверху вниз» или «снизу вверх». Хорошо структурированныесложные системы можно создать методом «возвратного проектирования».
Вдальнейшем будем называть этот процесс микропроцессом. В этом методе основноевнимание уделяется процессу поступательного итеративного развития путемсовершенствования различных, но, тем не менее, совместимых между собойлогических и физических моделей системы. Возвратное проектирование составляетнеобходимую основу процесса объектно-ориентированного проектирования.
Микропроцессобъектно-ориентированной разработки приводится в движение потоком сценариев иархитектурных продуктов, которые порождаются и последовательно уточняются вмакропроцессе. Микропроцесс, по большей части, — повседневный труд отдельногоразработчика или небольшого коллектива разработчиков.
Микропроцессотносится в равной степени к программисту и архитектору программной системы. Сточки зрения программиста, микропроцесс предлагает руководство в принятиибесчисленного числа ежедневных тактических решений, которые являются частьюпроцесса создания и подгонки архитектуры системы. С точки зрения архитектора,микропроцесс является основой для развития архитектуры и опробованияальтернатив. В микропроцессе традиционные фазы анализа и проектированияумышленно перемешаны.

/>
Рис.15. Микропроцесспроектирования
Какпоказано на рис.15, микропроцесс обычно состоит из следующих видов деятельности:
выявлениеклассов и объектов на данном уровне абстракции;
выяснениесемантики этих классов и объектов;
выявлениесвязей между этими классами и объектами;
спецификацияинтерфейса и реализация этих классов и объектов.
Рассмотримих более подробно:
1. Выявлениеклассов и объектов.
Цель: Выявленияклассов и объектов состоит в том, чтобы найти границы предметной области. Крометого, эта деятельность является первым шагом в продумыванииобъектно-ориентированной декомпозиции разрабатываемой системы. Этот шаг ванализе применяется тогда, когда обнаруживаются абстракции, составляющиесловарь предметной области и, тем самым, ограничивая задачу, решая, что важно,а что — нет. Такие действия необходимы при проектировании, когда мы изобретаемновые абстракции, которые являются составными частями решения. Переходя кпрограммной реализации, мы применяем процедуру выявления, чтобы изобрести болеепростые абстракции, из которых строятся более сложные, и обнаружить общие чертысуществующих абстракций, дабы упростить архитектуру системы.
Результаты:Главным результатом этого шага является обновляющийся по мере развитияпроекта словарь данных.
2. Идентификациясемантики классов и объектов.
Цель: Определитьповедение и атрибуты каждой абстракции, выявленной на предыдущем шаге. При этоммы уточняем намеченные абстракции, продуманно и измеримо распределяя между нимиобязанности.
Результаты:Во-первых, уточняется словарь данных, с помощью которого мы изначальноприсвоили обязанности абстракциям. В ходе проектирования можно выработатьспецификации к каждой абстракции, перечисляя имена операций в протоколе каждогокласса. Затем, необходимо выразить интерфейсы этих классов на языке реализации.Например, для C++ это означает создание. h-файлов, в Ada — спецификацийпакетов, в CLOS — обобщенных функций для каждогокласса, в Smalltalk — это объявление, но не реализацияметодов каждого класса. В добавление к этим, по сути тактическим решениям, мысоставляем диаграммы объектов и диаграммы взаимодействий, передающие семантикусценариев, создаваемых в ходе макропроцесса. Эти диаграммы формально отражаютраскадровку каждого сценария и, таким образом, описывают явное распределениеобязанностей среди взаимодействующих объектов. На этом шаге впервые появляютсяконечные автоматы для представления некоторых абстракций.
3. Выявлениесвязей между классами и объектами.
Цель: Уточнитьграницы каждой обнаруженной ранее в микропроцессе абстракции и опознать всесущности, с которыми она взаимодействует. Это действие формализуетконцептуальное и физическое размежевание между абстракциями, начатое напредыдущем шаге.
Результаты:Основными результатами этого шага являются диаграммы классов, объектов имодулей. Хотя в конце концов необходимо выразить решения, принятые при анализеи проектировании, на языке программирования, диаграммы дают более широкий обзорархитектуры и, кроме того, позволяют раскрыть отношения, которые с трудомформулируются на используемом языке реализации. Нет ни возможности, нинеобходимости создавать исчерпывающий набор диаграмм, которые определили бы всевозможные виды связей между нашими абстракциями. Нужно сосредоточиться лишь насамых важных отношениях, причем подразумевается, что в число важных входят тесвязи между абстракциями, которые отражают фундаментальные архитектурныерешения или выражают детали, необходимые для реализации.
4. Реализация классов и объектов.
Цель: Наэтапе анализа реализация классов и объектов нужна, чтобы довести существующиеабстракции до уровня, достаточного для обнаружения новых классов и объектов наследующем уровне абстракции; они сами будут в дальнейшем поданы на новуюитерацию микропроцесса. Этот шаг намеренно выполняется позже всех, так какмикропроцесс концентрирует внимание на поведении и откладывает наскольковозможно решения о представлении. Такая стратегия оберегает разработчика отнедозрелых решений, которые могут не оставить шансов на облегчение и упрощениеархитектуры, и оставляет свободу выбора реализации (например, из соображенийэффективности), гарантируя сохранение существующей архитектуры.
Результаты:Чтобы раскрыть связи между логическим и физическим в нашей реализациисистемы, вводятся диаграммы модулей, которые можно затем использовать, чтобынаглядно показать отображение архитектуры в ее программную реализацию. Далееможно применить специфические инструментальные средства (например CASE-средства), которые позволяют либо генерировать код издиаграмм, либо восстанавливать диаграммы по реализации. В этот шаг входит иобновление словаря данных, включая новые классы и объекты, которые быливыявлены или изобретены при реализации существующих абстракций. Эти новыеабстракции являются частью исходной информации для следующего цикламикропроцесса.
Контролирующимпо отношению к микропроцессу является макропроцесс. Макропроцесс предписываетряд измеримых результатов и действий, которые позволяют команде разработчиковоценить риск, внести заблаговременные изменения в микропроцесс исосредоточиться на коллективном анализе и проектировании. Макропроцесс — этодеятельность всего коллектива в масштабе от недель до месяцев./>/>/>4.6 Эволюция
Основнаяцель данного этапа — наращивать и изменять реализацию, последовательносовершенствуя ее, чтобы в конечном счете создать готовую систему. Эволюцияархитектуры в значительной степени состоит в попытке удовлетворить несколькимвзаимоисключающим требованиям ко времени, памяти и т.д. — одно всегдаограничивает другое. При эволюции системы на практике ожидаются следующие типыизменений:
добавлениенового класса или нового взаимодействия между классами;
изменениереализации класса;
изменениепредставления класса;
реорганизацияструктуры классов;
изменениеинтерфейса класса.
Первичнымрезультатом эволюции является серия исполнимых релизов, представляющихитеративные усовершенствования изначальной архитектурной модели. Вторичнымпродуктом следует признать выявление поведения, которое используется дляисследования альтернативных подходов и дальнейшего анализа «темных углов»системы. В начале процесса разработки основные действующие релизы передаютсяразработчиками контролерам качества, которые тестируют их по сценариям,составленным при анализе, и накапливают информацию о полноте, корректности иустойчивости работы релиза. Это раннее накопление данных помогает при выявлениипроблем качества, которые будут учтены в следующих релизах. Позднее действующиерелизы передаются конечным (альфа и бета) пользователям некоторым управляемымспособом. Это означает, что разработчики тщательно выверяют требования ккаждому релизу и определяют аспекты, которые желательно проверить и оценить./>/>/>4.7 Сопровождение
Этот этапразработки представляет собой управление эволюцией продукта в ходе егоэксплуатации. Он в значительной степени продолжает предыдущие фазы, заисключением того, что вносит меньше архитектурных новшеств. Вместо этогоделаются более локализованные изменения, возникающие по мере учета новыхтребований и исправления старых ошибок. Кроме тех требований, которые покаким-либо причинам не были учтены, вероятно, уже вскоре после выпускаработающей системы, разработчики и конечные пользователи должны обменятьсямножеством пожеланий и предложений, которые они хотели бы увидеть воплощеннымив следующих версиях системы. Чем больше с системой работает пользователей, тембольше может выявиться новых ошибок. Составляется список, в который заносятсяобнаруженные дефекты и новые требования, которые будут учтены при планированииновых релизов в соответствии с их приоритетом.
Типичныйпорядок действий на этом этапе таков:
упорядочиваютпо приоритетам предложения о крупных изменениях и сообщения об ошибках,связанных с системными проблемами;
составляютсписок этих изменений и принять их за функциональные точки в дальнейшейэволюции;
еслипозволяют ресурсы, планируют в следующем релизе менее интенсивные, болеелокализованные улучшения;
приступаютк разработке следующего эволюционного релиза программы./>/>/>4.8 Заключение
Взавершение этой главы можно сказать, что объектно-ориентированный методпроектирования со времени своего появления и до настоящего момента сталосновным и, с уверенностью можно утверждать, лучшим средством в разработкепрограммного обеспечения информационных систем. Этот метод не даетуниверсальных рецептов однозначно ведущих к успеху в разработке ПО. Какотмечает Страуструп, «не существует рецептов, которые могли бы заменитьум, опыт и хороший вкус в проектировании и программировании… Различные фазыпрограммного проекта, такие, как проектирование, программирование итестирование, неотделимы друг от друга». Однако, несмотря на это, процессобъектно-ориентированного анализа и проектирования определен достаточно хорошо,чтобы быть предсказуемым и воспроизводимым в умелых руках.
Необходимоподчеркнуть, что каждый проект уникален, и, следовательно, разработчик, если онпридерживается объектно-ориентированной методикой разработки, сам долженподдерживать баланс между неформальностью микропроцесса и формальностьюмакропроцесса, описанных выше.
/>/>5. Методика отладки и результаты работы программы
/>/>/>/> 5.1 Особенности тестирования программных продуктов
Программыкак объекты тестирования имеют ряд особенностей, которые отличают процесстестирования от традиционного, применяемого для проверки аппаратуры и другихтехнических изделий. С этой позиции основными особенностями программ являются:
отсутствиеполностью определенного эталона, по которому должны соответствовать всерезультаты тестирования проверяемого программного обеспечения;
высокаясложность программ и принципиальная невозможность построения тестовых наборов,достаточных для их исчерпывающей проверки;
невысокаястепень формализации критериев качества процесса тестирования и достигаемогопри этом качества программного обеспечения как объекта тестирования;
наличие впрограммах вычислительных компонент, а также компонент, характеризующихсястохастическим и динамическим поведением.
Неоднократноэкспериментально установлено, что в любом сложном программном обеспечении впроцессе эксплуатации обнаруживаются ошибки, даже если проведено самоетщательное тестирование. Тем самым объективно утверждается, что невозможноформализовать и обеспечить абсолютную полноту всех эталонных значений, а такжепровести всеобъемлющее исчерпывающее тестирование и гарантированно устранитьвсе ошибки в сложных программных продуктах. Поэтому тестирование проводится вобъемах, минимально необходимых для проверки программ в некоторых ограниченныхпределах изменения параметров и условий функционирования. Ограниченностьресурсов тестирования привела к необходимости тщательного упорядочения методови конкретных значений параметров с целью получения при тестировании наибольшейглубины проверок программ. Анализ многих проектов показывает, что до началатестирования число ошибок в сложных программах составляет порядка 1-2% отобщего числа объектных команд в программе, т.е. в программном обеспеченииобъемом 100 тысяч команд в процессе тестирования обычно выявляется 1-2 тысячиошибок. При тщательном системном проектировании и программировании на языкахвысокого уровня начальное число ошибок в несколько раз меньше. Таким образомсамое тщательное тестирование сложных программных комплексов позволяет получитьпрограммы с вероятностью ошибки в каждой команде порядка 10-4-10-5,т.е. несколько ошибок может остаться не выявленными.
/>/>/>/> 5.2 Типичный процесс тестирования программногообеспечения
Процесстестирования программ обычно включает:
созданиесовокупности тестовых эталонных значений и правил, которым должнасоответствовать программа по выполняемым функциям, структуре, правиламописания, значениям исходных и соответствующих им результирующих данных;
статическоетестирование текстов разработанных программ и данных на выполнение всехзаданных правил построения и описания без исполнения объектного кода;
тестированиепрограммы с её исполнением в объектном коде и с разными уровнями детализации: детерминированное,стохастическое, и тестирование в реальном масштабе времени;
диагностикуи локализацию причин отклонения результатов тестирования от заданных эталонныхзначений и правил;
разработкуизменения программы с целью исключения причин отклонения результатов отэталонных;
реализациюкорректировки программы, обеспечивающую соответствие программы заданномуэталону.
Статическоетестирование является наиболее формализованным и автоматизируемым методомпроверки корректности программ. В качестве эталонов применяются правиластруктурного построения программных модулей и обработки данных,конкретизированные для проекта в целом. Кроме того, могут использоватьсянекоторые частные правила обработки данных, зафиксированные в спецификациях наотдельные компоненты программ. Проверка степени выполнения этих правил проводитсябез исполнения объектного кода программы путём формального анализа текстапрограммы на языке программирования. Операторы и операнды текста программ приэтом анализируются в символьном виде, поэтому такой метод называют такжесимволическим тестированием. Развитие и углубление символического тестированияможет доводиться до уровня формальной верификации программы на соответствие еётекста детальной спецификации совокупности утверждений, полностью определяющейсвязи между входными и выходными данными этой программы.
Наиболеетрудоёмкими и детализирующими являются методы детерминированного тестирования. Придетерминированном тестировании контролируется каждая комбинация исходныхэталонных данных и соответствующая ей комбинация результатов функционированияпрограммы. Это позволяет выявлять отклонение результатов от эталона сконкретным фиксированием всех значений исходных и результирующих данных, прикоторых это отклонение обнаружено.
В сложныхпрограммах невозможно перебрать все комбинации исходных данных ипроконтролировать результаты функционирования программы на каждой из них. Втаких случаях применяется стохастическое тестирование, при котором исходныетестовые данные задаются множествами случайных величин с соответствующимираспределениями и для сравнения полученных результатов используются такжераспределения случайных величин. В результате при стохастическом тестированиивозможно более широкое варьирование исходных данных, хотя отдельные ошибкимогут быть не обнаружены, если они мало искажают средние статистическиезначения или распределения. Стохастическое тестирование применяется в основномдля обнаружения ошибок, а для диагностики и локализации ошибок приходитсяпереходить к детерминированному тестированию с использованием конкретныхзначений параметров из области изменения ранее использовавшихся случайныхвеличин.
Последующеерасширение области изменения исходных данных возможно при применениитестирования в реальном масштабе времени. В процессе такого тестированияпроверяется исполнение программ и обработка исходных данных с учётом времени ихпоступления, длительности и приоритетности обработки, динамики использованияпамяти и взаимодействия с другими программами и т.д. При обнаружении отклоненийрезультатов исполнения программ от предполагавшихся эталонных для локализацииошибки приходится фиксировать время и переходить к детерминированномутестированию./>/>/>/>/>/>5.3 Особенности задачи вприложении к тестированию программ
/>/>/>/>/> 5.3.1 Особенности среды программирования
Средапрограммирования Microsoft Visual Studio6.0 и язык программирования в ней Microsoft Visual C++ имеют ряд особенностей, влияющих на тестирование программ:
Visual C++является языком программирования высокого уровня, что сильно увеличиваетзначимость статического (символьного) тестирования;
средапрограммирования разработана для поддержки высокой степени использованиястандартных поставляемых в модулях процедур. Эти модули являются ужеоттестированными и испытанными. Считается, что вызываемые процедуры обладаютвысокой надёжностью и не содержат ошибок;
VisualStudio имеет развитую систему автоматической символьной проверки. Она на этапенаписания программы следит за корректностью вводимого текста и обнаруживает всесинтаксические ошибки;
вкомплект Visual Studio входит множество утилит для отладки, значительнооблегчающих процесс тестирования программного обеспечения;
большуючасть структуры программы в Visual C++ with Microsoft Foundation Classes занимают стандартные,автоматически создаваемые объекты, управляющие работой программы в ответ надействия пользователя. Поэтому ошибки в основном содержатся в алгоритмахпроцедур, написанных программистом.
/>/>/>/>/> 5.3.2 Основные факторы, влияющие на надежностьразрабатываемой системы
Представленнаяпрограмма регистрации процеса прохождения партий по технологическому маршруту,в силу предъявляемых к нему требований, создана для внесения строгоопределенной информации. Исходя из этого, можно выделить главные факторы,влияющие как на надежность данного программного обеспечения, так и нанадежность любого программного обеспечения:
корректностьструктуры программы;
корректностьобработки данных;
устойчивостьк ошибочному вводу данных пользователем.
Устойчивостьк ошибочному вводу данных пользователем осуществлена при помощи стандартныхпрограммных средств, реализованных в библиотеке MFC. Вводятся следующиеограничения на поля данных:
недопустимонепустое значение поля данных;
недопустимозначение поля данных, не входящее в заданный интервал допустимых значений.
В случаеввода неверных данных пользователю выводится на экран соответствующее сообщение.
/> 5.3.2.1 Контроль структуры программы
Корректностьструктуры программ определяется корректностью структуры модулей и корректностьюструктуры групп программ, построенных из модулей. Для оценки корректностиструктуры программ используется несколько частных показателей, различающихсястепенью охвата тестами структурных компонент программы при тестировании. Проверкакорректности структурных компонент производится статически по исходным текстампрограмм или динамически при исполнении программы в объектном коде. При обоихметодах по мере углубления критериев тестовых проверок возрастает объем исложность тестов, а следовательно и достигаемая степень корректности программ. Рассмотримодин из наиболее часто используемых критериев выделения тестируемых маршрутовдля проверки корректности структуры программы.
Сутькритерия состоит в выборе и анализе базовых маршрутов в программе, формируемыхи оцениваемых на основе определения цикломатического числа исходного графа,определяющего структуру программы или ее фрагмента. Критерий наиболее широкоприменяется для оценки сложности и корректности тестирования программныхмодулей. Для определения цикломатического числа Z исходного графафрагмента программы используется полное число его вершин Nп,связывающих их дуг Y и связных компонент L: Z = Y — Nп+ L. Вычисление цикломатического числа осуществляется по величинам,определяемым по максимально связному графу, который получается из исходногопутем замыкания дуги из конечной вершины в начальную. В результате вмаксимально связном графе появляются маршруты между любыми двумя вершинами. Приэтом предполагается, что исходный граф корректен, т.е. не содержит «висячих»и «тупиковых» вершин. В таком графе цикломатическое число равномаксимальному количеству его линейно-независимых маршрутов. Величина Lсоответствует количеству связных компонент всего исходного графа, и обычно дляграфов не содержащих полностью независимых частей L=1. Иначе говоря, Lизмеряется количеством замыкающих дуг, необходимых для преобразования исходногографа в максимально сильно связный граф.
Такимобразом, критерий учитывает каждый линейно-независимый цикл в максимальносвязном графе программы. Каждый линейно-независимый маршрут или цикл отличаетсяот всех остальных хотя бы одной вершиной или дугой, т.е. его структура не можетбыть полностью образована компонентами других маршрутов.
/>

Рис.16. Фрагмент исходного текста программы
Рассмотримна примере фрагмента кода разрабатываемого программного обеспечениятестирование корректности структуры этого фрагмента (см. рис.16). На основеданного фрагмента кода выделим операторы управления и построим графовую модельпрограммы по управлению. Цифрами на рис.16 условно обозначены вершины графа. Рис.17отображает схему этого графа.

/>
Рис.17. Граф программы по управлению
Далееопределим цикломатическое число графа по исходным данным:
Nп = 6
Y = 8
L = 1
Z = Y — Nп+ L = 3
В данномслучае для максимально связного графа количество линейно-независимых маршрутовдля которых следует подготовить тесты равно цикломатическому числу графа. Этимаршруты показаны на рис.18.
/>

Рис.18. Линейно-независимые маршруты
В итогедля проверки корректности структуры данного фрагмента кода необходимо провестистатическое и динамическое тестирование четырех полученных маршрутов./> 5.3.2.2 Контроль чтения и записи переменных
Корректностьобработки данных определяется степенью тестирования процесса обработкипредставительной выборки значений переменных в диапазонах их изменения. Длясложных программ принципиально невозможно провести исчерпывающее тестированиепри всех значениях переменных, которые могут появиться при реальномфункционировании программ.
Контрольчтения и записи переменных включает в себя две задачи: построениедиагностической модели программы с учетом информационных связей и просмотрмодели с целью выявления недопустимых сочетаний операций считывания и записивеличин. Схема структурных связей в виде направленного графа программыиспользуется как база для построения на модели программы информационных связеймежду операторами. Пример построения графа фрагмента программы приведен впредыдущем подразделе. Схема контроля детально показана на рис. 19.
Контрользаписи и чтения переменных сводится к последовательному просмотру частейпрограммы, которые образуют маршруты, ведущие от места считывания некоторойвеличины ко входам программы. При просмотре устанавливается:
существуетли запись этой величины вообще;
на всехли путях, ведущих ко входам, есть запись соответствующей величины передсчитыванием с той же области памяти;
незабивается ли считываемая величина записью другой величины, т.е. нет ли междузаписью и чтением дополнительной записи в ту же область памяти другой величины.

/>
Рис. 19. Схемаконтроля чтения и записи переменных
Также повсем маршрутам, ведущим из начальной вершины графа в конечную, выполняетсяконтроль наличия запрещенных сочетаний операций по всем наименованиям величин. Условиямиправильной реализации являются:
предварительнаязапись в область памяти перед считыванием из нее информации;
наличие виндексной переменной значения индекса требуемого наименования.
В итогевсе обнаруженные ошибки и сомнительные сочетания операций фиксируются иисправляются в тексте программы./>/>/> 5.4 Результаты работы программы
Нижеприведены результаты работы программы.
На рис.20показано главное меню программы, содержащее помимо стандартных элементовуправления (File, Windows, Help) специальные. Существенные объекты выделены вотдельное выпадающее меню Objects.
/>
Рис. 20. Главноеменю программы
На рис.21.показано окно вывода информации о процессе обработки, выполняемой над партиейполупроводниковых пластин с заданным номером в пределах заданного изделия. Приэтом выводится вся необходимая информация о маршруте, параметрах и режимахтехнологической операции, рассчитывается время окончания технологическойоперации.
/>
Рис.21. Окновывода результатов выполнения технологической операции
На рис.22показано окно вывода информации о техологических операциях, произведенных надпартией полупроводниковых пластин с момента ее запуска в производство. Вприведенной таблице отображаются не только номера и названия технологическихопераций, но и параметры обработки, время фактического начала и окончанияобработки. Расположенные над таблицей фильтры позволяют выбрать диапазон,охватывающий либо весь период существования партии полупроводниковых пластин смомента ее запуска в производство, либо заданный интервал времени и отобразитьоперации, произведенные над партией пластин в этот период.
/>
Рис.22. Окновывода информации о технологических операциях, произведенных над партиейполупроводниковых пластин
/>6. Организационно-экономическаячасть/>/>6.1 Введение
Особенности процесса создания и освоения новойтехники, в том числе постановки сложной современной продукции в производстве,связаны с чрезвычайно большим количеством разнообразных операций и действий,выполняемых различными подразделениями и коллективами. Во многих случаях этаколлективы не соподчинены, имеют противоречивые интересы и не управляются изединого центра. В то же время все работы и процессы должны выполнятьсяслаженно, согласованно и по возможности в кратчайшие сроки. Именно этоготребуют задачи научно-технического прогресса, успешное решение которыхчрезвычайно актуально для нашей отечественной промышленности.
Рассмотренные особенности планирования требуют,во-первых, надежной координации всех звеньев и подразделений, выполняющих тотили иной проектируемый комплекс работ, и, во вторых, использования методовоптимизации сроков, затрат и ресурсов, необходимых для реализации проекта. Кнаилучшим планово-координационным инструментам из известных в настоящее времяотносятся модели, на базе которых созданы системы сетевого планирования иуправления (СПУ).
Работы по развитию и использованию СПУ получилибольшое распространение за рубежом. В нашей стране многими организациями ипредприятиями также накоплен опыт применения систем СПУ. Они эффективноиспользуются в разных отраслях при создании и освоении новой техники, при строительствеи пуске крупных объектов, ремонте уникальных агрегатов, координации крупныхнаучно-исследовательских работ, реализации межотраслевых проектов. Следует в тоже время отметить, что большим достижением использования СПУ в нашей странеявляется то, что с самого начала ее внедрения были приняты меры по обеспечениюединообразия терминов, обозначений, методов расчетов, — словом, по максимальнойунификации системы.
Система СПУ создана в первую очередь дляпланирования комплекса работ, носящих характер неопределенности. С помощьюсетевых графиков и методов их расчета (рассмотренных ниже) успешнопреодолеваются осложнения, связанные о неопределенностью в оценках времени,необходимого для выполнения отдельных работ, в сроках достижения промежуточныхи конечного результатов, в потребных ресурсах.
Сетевые графики обеспечивают строгую увязку икоординацию всех работ, входящих в комплекс проекта.
Определение величины затрат, связанных овыполнением исследовательских, конструкторских, технологических этапов, сизготовлением опытного образца, в значительной море облегчается при примененииметодов СПУ, поскольку становятся известными оценки времени с достаточной длястохастических процессов точностью. Подсчет количества и состава участниковработы производится согласно ожидаемым затратам времени (или исходя извременных ограничений) на каждую работу. Определение после этого затрат назаработную плату, материалы, … осуществляется известными методами, а уровнинакладных расходов берутся в соответствии с данными конкретного предприятия.
Особенно целесообразно использовать методологиюСПУ, когда планируются комплексные разработки, имеющие вероятностный характеркак по составу работ, так и по времени их выполнения.
Необходимым условием планирования и управленияработами является возможность не только оценки текущего состояния, но ипредсказания дальнейшего хода работ и, таким образом, воздействия на ихвыполнение (при этом имеется в виду, что весь комплекс работ выполнен в сжатыесроки и о наименьшими затратами).
График как элемент системы планирования иуправления должен отражать те стороны выполняемых работ, которые являютсясущественными в отношении достижения конечных целей.
Основным элементом системы является сетевойграфик. Это плановая модель процесса, на которой можно провести эксперименты ивыявить, к каким результатам приведет то или иное изменение сроков выполненияотдельных работ.
В системе используется графическое отражениелогической последовательности, взаимосвязи и продолжительности работ.
Сетевые графики можно классифицировать по объемуи степени детализации, по степени определенности, по числу достигаемых целей (результатов),по вероятности сроков выполнения отдельных приемов и работ.
По объему и степени детализации различают:
первичные,
частные,
комплексные сети.
По степени определенности:
детерминированные сети, когда известна конкретнаяцель разработки и основные процессы, ведущие к ее достижению,
стохастические сети, когда возможныальтернативные варианты хода выполнения работ.
По числу конечных целей модели подразделяются на:
одноцелевые, когда заключительный результат всегокомплекса работ в сети является единственной целью данной работы.
многоцелевые, когда выполнение всего комплексаработ приводит к получению нескольких заключительных результатов, сеть в этомслучае завершается несколькими событиями.
Исходя из признака вероятности сетевые моделимогут создаваться как на основе нормативных данных о продолжительностивключаемых в модель работ (детерминированные модели), так и на осаовевероятностной (предположительной) оценки их продолжительности (вероятностныесетевые модели). Кроме сроков выполнения работ, сетевье модели могут включать идругие важные данные: величину затрат на выполнение действий, наличие ресурсови т.п.
СПУ состоит из следующих стадий:
предпроектной, включающей выбор объектапланирования;
создания сетевой модели, основанного на перечневсех работ и событий (промежуточных результатов);
оптимизации модели по установленным критериям (например,срокам или затратам);
управления с помощью сетевого графика на основепоступающей информации о ходе выполнения работ на данный период.
В данной работе рассматривается детерминированнаяодноцелевая модель. При исследовании рассматриваемой модели будут пройдены всестадии сетевого планирования и управления, включая выбор объекта планирования,создание сетевой модели, анализ и оптимизация.
 6.2 Сетевая модель, ее основные элементы, правилапостроения
Основным плановым документом в системах СПУявляется сетевой график, представляющий собой информационно-динамическуюмодель, в которой отражаются взаимосвязи и результаты всех работ, необходимыхдля достижения конечной цели разработки. Кроме того, модель содержит и другиехарактеристики (временные, стоимостные, ресурсные), относящиеся к отдельнымработам или ко всему комплексу. В сетевом графике детально или укрупненно показываетсяпоследовательность, время, условие, выполнение которого обеспечит окончаниевсех работ не позже заданного (директивного) срока. В основе сетевогомоделирования лежит изображение планируемого комплекса работ в виде графа. Граф- это схема, состоящая из заданных точек (вершин), соединенных определеннойсистемой линий. Отрезки, соединящие вершины, называются. ребрами (дугами) графа.Ориентированным нарывается, такой граф, на котором стрелкой указаны направлениявсех его ребер (дуг), т.е. для каждой дуги указано, какая из двух ее вершинявляется начальной, а какая — конечной.
Математическая теория графов оперирует понятиемпути, под которым понимается такая последовательность ребер, когда конецкаждого предыдущего ребра совпадает о началом последующего.
Сетевой график — это ориентированный граф безконтуров, ребра которого имеют одну или несколько числовых характеристик. Понятиеконтура означает конечный путь, у которого начальная вершина совпадает сконечной.
Таким образом, в отличие от ленточного графика,где основным является только один элемент — работа, в сетевом графике, какправило имеются два основных элемента — работа и событие.
Работами называются любые процессы, действия,приводящие к достижению определенных результатов (событий).
Кроме работ действительных, требующих затратвремени, в сетевых моделях могут содержаться так называемые фиктивные работы (зависимости).Фиктивной работой (зависимостью) называется связь между отдельными результатамиработ (событиями), не требующая затрат времени вообще или требующая минимальныхзатрат времени. К таким работам относится, в частности, передача по телефонунеобходимой информации.
Работа в сетевом графике изображается стрелкой. Каждаястрелка означает затраты времени, необходимого для выполнения соответствующейработы. Величина затрачиваемого на работу времени указывается над стрелкой. Дляотображения на графике фиктивных работ используются пунктирные стрелки, надкоторыми время на указывается.
Событиями называются результаты производственныхработ. Каждое событие может быть отправным моментом для начала последующихработ. В отличие от работы, имеющей обычно протяженность во времени, событиепредставляет собой только момент свершения работы (или работ).
Первоначальное событие в сети, не имеющеепредшествующих событий и отражающее начало выполнения всего комплекса работ,включенных в данную сеть, называется исходным и обозначается символом J. Событие, которое не имеет последующих событий и отражает конечную целькомплекса работ, включенных в данную сеть, называется завершающим иобозначается символом C.
Любая последовательность работ в сетевом графике,в которой конечное событие одной работы совладает с начальным событиемследующей за ней работы, называется путем.
В сетевом графике следует различать несколько видовпутей:
от исходного события до завершающего события — полныйпуть, или просто путь;
от исходного события до данного — путь,предшествующий данному событию;
от данного события до завершающего — путь,последующий за данным событием;
путь между исходным и завершающим событием,имеющим наибольшую продолжительность — критический путь.
Все события и работы, которые необходимовыполнить для peaлизации проекта, необходимо систематизировать присоставлении перечня событий и работ.
В перечне указываются кодовые номера инаименования событий, начиная с нулевого или первого, определяющего решение оначале работ, перечисляются работы, выходящие из каждого события, даются ихкоды. Код работы состоит из кодов начального и конечного для данной работысобытий, следующие графы перечня предусматривают простановку оценок временивыполнения работ.

Таблица 1.Перечень событийНомер Событие Решение о начале работ принято 1 Рабочая документация проанализирована 2 Опрос работников предприятия произведен 3 Существующие решения проанализированы 4 Полученная ннформация систематизирована 5 Аппарат имитационного моделирования создан 6 Разработаны возможные варианты дисциплины очереди 7 База данных разработана 8 Имитационная модель написана 9 Варианты протестированы 10 Имитационная модель сопряжена с базой данных 11 Пользовательский интерфейс разработан 12 Оптимальный вариант дисциплины очереди выбран 13 Имитационная модель цеха разработана 14 Имеющиеся ресурсы проанализированы 15 Аппаратная часть системы выбрана 16 Программные технологии системы выбраны 17 Система разбита на взаимосвязанные блоки 18 Разработка компьютерной системы завершена /> />

Рис.23. Сетевой график разработки автоматизированнойсистемы управления производственным процессом на предприятии электроннойпромышленности

Таблица 2Перечень работНомер Содержание работы 0-1 Анализ рабочей документации 1-3 Анализ существующих решений в управлении 3-4 Систематизация полученной информации 0-2 Опрос работников предприятия 2-3 Передача информации 3-7 Разработка базы данных 7-8 Передача информации 4-6 Разработка возможных вариантов дисциплины очереди 6-9 Тестирование вариантов дисциплины очереди 9-12 Выбор оптимального варианта 12-13 Разработка имитационной модели 4-5 Создание аппарата имитационного моделирования 5-8 Написание имитационной модели 8-10 Сопряжение имитационной модели с базой данных 10-12 Передача информации 4-11 Разработка пользовательского интерфейса 11-12 Передача информации 13-14 Анализ имеющихся программных и аппаратных ресурсов 14-17 Разбиение проектируемой системы на взаимосвязанные блоки 17-18 Разработка компьютерной системы 14-15 Выбор аппаратной части системы 15-17 Передача информации 14-16 Выбор программных технологий компьютерной системы 16-17 Передача информации
 6.3 Расчет параметров сетевой модели
К основным параметрам сетевой модели относятсякритический путь, резервы времени событий и работ. Эти параметры являютсяисходными для получения ряда дополнительных характеристик, а также для анализасети или, что то же самое, для анализа составленного плана разработки.
Расчет параметров сети имеет целью определение ихчисленных величин: продолжительности критического пути, размеров резервоввремени событий и работ и др. Этот расчет приводится далее.
В результате расчета параметров и анализа ихвеличин появляется возможность оптимизации сетевого графика по выбранным илиназначенным критериям. Расчет параметров и нахождение их определенных величинвозможны для детерминированных и условно-детерминированных моделей.
Критический путь — это наиболее протяженная повремени цепочка работ, ведущих от исходного к завершающему событию. Изменениепродолжительности любой работы, лежащей на критическом пути, соответственнымобразом меняет (приближает или отдаляет) момент наступления завершающегособытия, т.е. дату достижения конечной цели разработки.
Поскольку продолжительность критического пути определяетсрок выполнения всего комплекса работ, в процессе управления ходом разработкивнимание руководства сосредотачивается на главном направлении — на работахкритического пути. Это позволяет более рационально и оперативно контролироватьограниченное число работ, влияющих на срок разработок, а также лучшеиспользовать имеющиеся ресурсы (трудовые и материальные).
Критические пути резервами не располагают. Насетевом графике они изображаются обычно жирной линией.
В сетевых графиках имеются и другие пути, опирающиесяна исходное и завершающее события (полные пути), которые могут либо полностьюпроходить вне критического пути, либо частично совпадать с критическойпоследовательностью работ. Эти пути называются ненапряженными. Они попродолжительности меньше критического пути.
Ненапряженные пути обладают важным свойством: научастках, не совпадающих с критической последовательностью работ, они имеютрезервы времени.
Кроме критического пути, другими основнымипараметрами сетевой модели являются резервы времени наступления события иразновидности резервов времени работ. Резервы времени существуют в сетевомграфике во всех случаях, когда имеются два или более путей разнойпродолжительности. Резерв времени события — это такой промежуток времени, накоторый может быть отсрочено наступление данного события без нарушения сроковзавершения разработки в целом. Резерв времени события определяется как разностьмежду поздним Тп и ранним Тр сроками наступления события:
R = Т п — Т р.
Поздний срок наступления события Тп — максимальныйиз допустимых моментов наступления данного события, при котором возможнособлюдение расчетного срока наступления завершающего события. Превышение Тпвызовет аналогичную задержу наступления завершающего события. Иными словами,если событие наступило в момент Тп, оно попало в критическую зону и последующиеза ним работы должны находиться под таким же контролем, как и работыкритического пути.
Ранний срок наступления события Тр — минимальныйсрок, необходимый для выполнения всех работ, предшествующих данному событию. Этовремя находится путем выбора максимального значения из продолжительностей всехпутей, ведущих в данному событию.
Если обозначить предшествующее событие i, а последующее j, то ранний и поздний сроки свершения событийбудут обозначаться соответственно Трi, Тпi,Трj, Тпj, т.е. рядом с индексом, определяющим характер срока свершения события(ранний срок — р, поздний — п), пишется номер события.
В каждой сети для некоторых событий, которыеимеют нулевой резерв времени, наибольший допустимый срок равен наименьшемуожидаемому. Путь, соединяющий эти события, и является критическим, т.е. онсоответствует максимальной продолжительности последовательно выполняемых работ,ведущих от исходного к завершающему событию. Исходное и завершающее события вовсех случаях имеют нулевой резерв времени.
Зная ранние и поздние сроки наступления событий,можно для любой работы (i,j) определить также ранние и поздние срокиначала и окончания работы.
Ранний срок начала работы:
Т рн ij = Т р i
поздний срок ее начала:
Т пн ij = Т п j — t ij
ранний срок окончания работы:
Т ро ij = Т р i + t ij
поздний срок окончания работы:
Т по ij = Т п j.
Все названные сроки можно определять каккалендарные (задаваемые от начального момента календарной датой).

Рис.24. Параметры сети, отмеченныенепосредственно на графе: продолжительность работ, количество исполнителей,ранние и поздние сроки наступления событий, резервы времени событий.
/>

Резервами времени располагают не только события,но и пути (кроме критического), а также работы, лежащие на некритических путях.Для определения полного резерва времени пути R (Li) следует опять вернуться в тому условию, что длина критического пути всетевом графике больше, чем длина любого другого полного пути. Разница междудлиной критического пути t (Lкр) и длиной любого другогопути t (Li) называется полным резервомвремени пути:
R (Li) = t (Lкр) — t (Li)
Полный резерв пути показывает, насколько могутбыть увеличены продолжительности всех работ, принадлежащих пути Li, в сумме или, иными словами, каково предельно допустимое увеличениепродолжительности этого пути.
При определении резерва времени работы следуетучитывать, что работа может принадлежать нескольким путям одновременно. Полныйрезерв времени этой работы равен резерву времени максимального по продолжительностииз путей, проходящих через эту работу и не может быть больше его.
Полный резерв времени работы — это максимальноеколичество времени, на которое можно увеличить продолжительность данной работы,не изменяя при этом продолжительности критического пути. Полный резерв времениработы:
R п ij = Т п j — Т р i — t ij
где i — начальное событие даннойработы; j — конечное событие этой работы; Тпj и Трi — соответственно поздний иранний срок свершения событий i и j.
Важным свойством полного резерва времени работыявляется то, что при использовании его частично или целиком для увеличениядлительнооти какой-либо работы соответственно уменьшится резерв времени всехпоследующих работ, лежащих на этом пути. При использовании полного резервавремени целиком для одной работы резервы времени остальных работ, лежащих намаксимальном пути, проходящем через нее, будут полностью исчерпаны, посколькуполный резерв времени работы принадлежит не только ей, но и всем работам,лежащим иа путях, проходящих через данную работу. Резервы времени работ,лежащих на других (не максимальных по продолжительности) путях, проходящихчерез эту работу, сократятся и будут равны разности между прежним резервомвремени этих работ и использованным резервом времени работы, лежащей на максимальномпути.
У отдельных работ помимо полного резерва времениимеется свободный резерв времени Rс, который равен разностимежду ранними сроками наступления начального i и конечного j событий за вычетом продолжительности работы t ij:

R с ij = Т р j — Т р i — t ij
Свободный резерв времени — это максимальноеколичество времени, на которое можно увеличить продолжительность работы илиотсрочить ее начало, не изменяя при этом ранних сроков начала последующихработ, при условии, что начальное событие этой работы наступило в свой раннийсрок.
Если начальное событие iнаступает не в свой ранний срок, а в какой-то фактический Тф, то работа (i,j) будет располагать свободным фактическимрезервом времени:
R сф ij = Т р j — Т ф i — t ij
Используя свободный резерв времени, ответственныеисполнители могут беспрепятственно маневрировать в его пределах сроком началаданной работы или ее продолжительностью. Это важное свойство свободного резервавремени должно учитываться исполнителями при независимом выполнении отдельно взятыхработ, располагающих этим резервом.
Полные резервы времени работы так же позволяютманеврировать сроками начала и окончания работы, но в этом случае изменяютсярезервы последующих работ. При отсутствии резервов возможности подобногоманеврирования нет.
В то же время необходимо правильно использоватьимеющиеся резервы. Процесс оптимизации сетевых графиков, как показано вдальнейшем, в значительной мере связан о использованием резервов времени работ.Ответственные исполнители и руководители работ должны знать величину резервов ивозможности их использования.
Полный резерв времени работы может бытьраспределен, как отмечалось, между работами, находящимися на пути, которомупринадлежит данная работа. При этом и начальное, и конечное события этой работымогут располагать резервами времени.
Свободный резерв — это независимый резерв. Егоиспользование на какой-либо работе не меняет величины свободных резервовостальных работ сети, так как при его исчислении в качестве плановых сроковначала выполнения всех работ приняты ранние сроки наступления событий.
Таблица 3.Параметры сетевой моделиi j Трi Тпi Трj Тпj Tij Трнij Тпнij Троij Тпоij Rпij Rсij 1 4 4 4 4 4 1 3 4 4 9 9 5 4 4 9 9 3 4 9 9 17 17 8 9 9 17 17 2 4 9 4 5 4 9 5 2 3 4 9 9 9 4 9 4 9 5 5 3 7 9 9 28 40 17 9 21 28 40 12 7 8 28 40 38 40 28 40 28 40 12 10 4 6 17 17 25 25 8 17 17 25 25 6 9 25 25 40 40 15 25 25 40 40 9 12 40 40 45 45 5 40 40 45 45 12 13 45 45 55 55 10 45 45 55 55 4 5 17 17 24 26 7 17 19 24 26 2 5 8 24 26 38 40 14 24 26 38 40 2 8 10 38 40 43 45 5 38 40 43 45 2 10 12 43 45 45 45 43 45 43 45 2 2 4 11 17 17 19 45 2 17 43 19 45 26 11 12 19 45 45 45 19 45 19 45 26 26 13 14 55 55 57 57 2 55 55 57 57 14 17 57 57 67 67 10 57 57 67 67 17 18 67 67 82 82 15 67 67 82 82 14 15 57 57 61 67 4 57 63 61 67 6 15 17 61 67 67 67 61 67 61 67 6 6 14 16 57 57 61 67 4 57 63 61 67 6 16 17 61 67 67 67 61 67 61 67 6 6  6.4 Основы оптимизации сетевого графика
Получение параметров сетевого графика позволяетперейти в следующему этапу сетевого планирования. На этом этапе, которыйраскрывает одну из основных идей СПУ, выполняется всесторонний анализсозданного графика и предпринимаются меры для его оптимизации. Конечная цельэтих работ — приведение сетевого графика в соответствии с заданными сроками иодновременно возможностями организаций, осуществляющих разработку. Анализсетевого графика, опиравшийся на результаты расчетов, включает оценкуцелесообразности и структуры графика, загрузки исполнителей работ на всехэтапах выполнения проекта, возможности смещения начала работ некритической зоныи, наконец, оценку вероятности наступления события в заданный срок.
Предварительный анализ построенного графавключает просмотр топологии сети, контроль правильности выполнения построения иего структуры, установление целесообразности степени детализации работ.
Следующим этапом анализа может быть классификацияи группирование работ по величинам резервов (полных и свободных). При этомследует подчеркнуть, что далеко не всегда величина полного резерва можетдостаточно точно характеризовать, насколько напряженным является выполнение тойили иной работы некритической зоны. Все зависит от того, на какую последовательноотьработ распространяется вычисленный резерв, какова величина (протяженность) этойпоследовательности. Иными словами, важно не только абсолютное, но иотносительное значение резерва работы или отрезка пути.
Определить сложность выполнения в срок каждойгруппы работ некритического пути можно с помощью коэффициента напряженности — этоотношение продолжительности отрезка наибольшего из некритических путей,проходящих через данную работу, к продолжительности несовпадающего отрезкакритического пути, проходящего через эту работу.
Если совпадающую с критическим путем величинуотрезка пути обозначить t' (Lкр), длину критического пути- t (Lкр), а протяженностьмаксимального из некритических путей, проходящих через данную работу, — t (Lmax), то коэффициент напряженности Kнij будет равен:

/>
Используя зависимость, по которой определяетсяполный резерв времени пути, формулу можно привести к виду:
/>
Как отмечалось, работы могут обладать одинаковымполным резервом, но степень их критичности (или коэффициент напряженности) будетразличной. И наоборот, одинаковым полным резервам могут соответствоватьсовершенно различные коэффициенты напряженности.
Чем выше коэффициент напряженности, тем сложнеевыполнить данную работу в установленные сроки. И наоборот, чем меньшекоэффициент напряженности, тем большими относительными резервами обладаетданный путь в сети.
По полученным таким образом коэффициентамнапряженности все работы распределяются по зонам (критическая, подкритическая ирезервная). Критическая зона сетевого графика — это совокупность путей, включаякритический, абсолютные значения резервов времени которых меньше заданнойвеличины. Можно сказать и иначе — это совокупность работ, имеющих коэффициентынапряженности, близкие к единице. Как показывает практика, объем критическойзоны составляет 10 — 15% всего числа работ сетевой модели. Резервная зона — этосовокупность работ, имеющих коэффициенты напряженности значительно меньшеединицы. 6.5 Анализ и оптимизация сетевой модели
Оптимизация сетевого графика представляет собойпровесс улучшения организации выполнения комплекса работ с целью соблюденияустановленного срока и выделения ресурсов. Она осуществляется за счет факторов:
перераспределения ресурсов — временных (использованиерезервов времени), материальных, финансовых, а также ресурсов рабочей силы;
интенсификации выполнения работ критического пути(дополнительное количество исполнителей и оборудования, материальноестимулирование, сверхурочные работы);
параллельного выполнения работ критического пути;
изменения в характере комплекса работ.
Оптимизация сетевого графика в зависимости отполноты решаемых задач может быть условно разделена на частную и комплексную. Видамичастной оптимизации сетевого графика является минимизация:
времени выполнения разработки при заданной еестоимости;
потребляемых (используемых одновременно) ресурсов;
стоимости всего комплекса работ при заданномвремени выполнения проекта.
Комплексная оптимизация сетевого графина — этонахождение оптимума в соотношениях величин затрат и сроков выполнения проекта взависимости от конкретных целей, ставящихся при его реализации. Решение задачиполной оптимизации всецело зависит от значимости и степени срочностивыполняемого комплекса работ. В одних случаях целесообразно увеличение затратпо сравнению с их нормальней величиной в целях сокращения сроков, в другихпревалирует экономия затрат, а с некоторым увеличением сроков разработки можномириться.
При минимизации времени выполнения работ (оптимизациипо критерию «время») общий срок выполнения разработки следуетсокращать а первую очередь за счет изменения продолжительности критическихработ. Это шаг не связан с изменением топологии, сеть не вычерчивается заново,меняются лишь временные оценки. Следует иметь в виду, что при значительномсовращении сроков выполнения критических работ уменьшаются и резервы временинекритических путей, в результате чего постепенно возрастает число критическихпутей. В перспективе все пути могут стать равнонапряженными и иметь одинаковуюпродолжительность.
Сокращение продолжительности критического путиможет быть достигнуто ответственными исполнителями критических работ за счетвнутренних резервов, а также путем привлечения дополнительных ресурсов. Внутренниерезервы работ, подчиненных одному ответственному исполнителю, заключаются винтенсификации выполняемых действий в лучшей организации работ, повышенииуровня их автоматизации. Напримар, системы автоматического проектирования (САПР)позволяют во много раз ускорить процессы расчетов, отбора лучших вариантов избольшого числа просчитанных, быстро найти наилучшее решение. Во многих случаяхинтенсификация приводит к повышению затрат.
Выделение дополнительных ресурсов для критическихработ, естественно, представляется более привлекательным для ответственныхисполнителей этих работ, чем интенсификация. Откуда могут быть получены этиресурсы? Обычно речь идет не о внешних для проекта в целом источникахувеличения ресурсов, а о перераспределении ресурсов (например, работников) междуработами резервной и критической зон. Переброска работников с некритическихработ на критические сопровождается увеличением сроков выполнения некритическихработ и сокращением располагаемых ими резервов. Резервы этих работ будутсокращаться в связи с увеличением их продолжительности и одновременно ссокращением продолжительности критических работ.
Наглядно представить процесс изменения резервоввремени и потребности в исполнителях на отдельных этапах выполнения проекта вцелом можно с помощью так называемой карты проекта, в которую с этой цельюпреобразуется исходная сетевая модель. Перед таким преобразованием на самомсетевом графике вводится дополнительная информация: под стрелкой каждой работыдаются сведения не только о ее продолжительности, но и о потребности вразличиях категориях работников. Карта проекта отражает календарные срокивыполнения работ и необходимое количество работников каждой категории насоответствующем этапе. Такая карта может быть получена из обычной сети посленахождения критического пути.
Ход преобразования сетевой модели в карту проектаследующий. Проводится оценка потребного количества работников для выполнениякаждой отдельной работы комплекса. На сетевом графике под стрелкой каждойработы указано число работников, необходимых для выполнения данной работы.
После этого сетевая модель преобразуется вкалендарный график (карту проекта). Критический путь на сетевом графикеизображается жирной прямой линией в масштабе времени вдоль оси абсцисс. Тогдавсе остальные работы можно отложить выше и ниже критического пути. Ониизображаются тонкими стрелками, длина которых пропорциональна продолжительностиработ.
Пунктирные линии играют вспомогательную роль (соединениеработы с событиями) и дают наглядное представление об имеющихся резервахвремени. Если по каким-либо причинам некритическая работа начинается не сразупосле наступления предшествующего события, ее обозначают пунктирной линией. Фиктивныеработы вычерчиваются только пунктирными линиями. При отсутствии резерва ониизображаются на карте вертикальной пунктирной линией.
Под календарным графиком изображаются диаграммыдотребнооти в работниках.
Маневрирование ресурсами работников, сокращениеих числа или же уменьшение общей продолжительности комплекса работ возможно приусловии двух предпосылок:
если специалисты, выполняющие параллельныеработы, взаимозаменяемы;
если эти группы специалистов подчинены одномуруководителю.
При отсутствии предпосылок дальнейшая (послерациональной перестройки сети) оптимизация и сокращение сроков могутпотребовать выделения дополнительных ресурсов — работников и средств на работыкритического пути.
Предположим, что либо мероприятиями ноинтенсификации работ критического пути. либо переброской исполнителей с работнекритического пути на критический, либо тем и другим образом критический путьсетевого графика совращён.
Следовательно изменяется карта проекта. Иными вэтом случае стали и диаграммы потребности в исполнителях вследствие ихперераспределения между работами критической и некритической зоны. Следующимэтапом является минимизация потребности в исполнителях. Это достигается путемсмещения сроков начала (и соответственно окончания) работ напряженных путей.
Работы подкритических путей располагают малымивозможностями для смещения их начала в ту или другую сторону. На графике этиработы образуют почти непрерывную цепочку сплошных горизонтальных линий, лишьместами имеющих пунктирные участки. В то же время работы путей, имеющих большиерезервы, допускают значительные вариации во времени их начала. Величинысмещений начала работ могут быть найдены по приведенным выше формулам сроковначала и окончания работ.
/> />
Рис.25. Карта проекта до оптимизации: календарныйграфик
/>
Рис.26. Карта проекта до оптимизации: диаграммапотребности в исполнителях
/>
Рис.27. Карта проекта после оптимизации: диаграммапотребности в исполнителях.
/>6.6 Выводы
В результате рассмотрения методов сетевогопланирования и управления можно сделать вывод о ряде преимуществ систем СПУ.
Внимание концентрируется на решающих работах,лежащих на критическом пути и относящихся к ограниченному числу ответственныхисполнителей. Управление строится по принципу временного исключения из полязрения руководства тех работ, которые в данный момент и в ближайшем будущем немогут влиять на общий ход разработки.
Практически реализуется принцип непрерывностипланирования хода работ и управления им. Систематическая корректировка плана исвоевременное принятие решений полностью подчинены задаче завершения разработкив заданные сроки.
Система СПУ обеспечивает возможностьрационального маневрирования выделенными для данной разработки ресурсамивремени и средств.
Упрощается и унифицируется отчетная документация.
Обеспечивается возможность использования ЭВМ длясоставления анализа, расчета и корректировки графиков выполнения работ.
Появляется возможность обосновать и математическиоптимизировать план реализации намеченных сложных комплексов работ, что непозволяют другие методы планирования вероятностных процессов.
В рассмотренном сетевом графе для выполнениявсего комплекса работ привлекалась только одна категория исполнителей работ — инженеры.
Анализ сетевого графика выявил работыкритического пути, общая продолжительность которых составила 82 дня. Оптимизациясетевого графика ставила своей целью обеспечение равномерности загрузкиисполнителей на всем протяжении критического пути. В результате были рассчитанырезервы времени событий и работ, в соответствии с которыми были изменены срокиначала некоторых работ, не принадлежащих критическому пути. Это позволилоуменьшить максимальную потребность в исполнителях и сократить штатноерасписание с 11 до 9 человек. В конечном счете затраты на выполнение всегокомплекса работ сократились со 150150 руб. до 122850 руб. Экономия отоптимизации в абсолютном выражении составила 27300 руб., что составляет 18% отпервоначальной стоимости.
Таблица 4. Результаты оптимизацииПараметры
После
оптимизации
До
оптимизации Штатное расписание, чел. 9 11 Заработная плата инженера, руб. /мес. 5000 5000 Длительность проекта, дн. 82 82 Всего затраты на проект, руб. 122850 150150 Экономия,% 18
/>7. Производственная иэкологическая безопасность
/> 
Организациярабочего места программиста и пользователя ЭВМ.
Выполнил:
Ляшко М.А.
Консультант:
НикулинаИ.М.
/> 7.1 Введение
Насовременном этапе развития электронной промышленности создание новой техникиставит задачу не только облегчить труд человека, но и привести к изменению егороли и места в производственном процессе. В условиях технического прогрессаувеличивается количество объектов, которыми он должен управлять, возрастаютскорости управляемых им процессов, широкое применение получает дистанционноеуправление. В связи с этим возрастает роль охраны труда, призванной не толькооблегчить труд человека, но и сделать условия труда комфортными.
Прииспользовании человеком даже самой передовой технологии у него могут возникнутьсоответствующие профессиональные заболевания, если работая, он будетпренебрегать даже элементарными правилами техники безопасности. Типичнымиощущениями, которые испытывают к концу рабочего дня чрезмерно увлеченные ибеспечные пользователи персональных компьютеров, являются: головная боль, резьв глазах, тянущие боли в мышцах шеи, рук и спины, зуд кожи на лице и т.д. Испытываемыедень за днем, они могут привести к мигреням, частичной потере зрения, сколиозу,кожным воспалениям и другим нежелательным явлениям. Все это не случайно.
Вероятнеевсего, человеку уже никогда не удастся полностью избежать пагубного влиянияпередовых технологий, но, как и во многих других случаях, сами пользователиперсональных компьютеров, по крайней мере, могут свести их к минимуму. Большинствопроблем решаются сами собой при правильной организации рабочего места, соблюденииправил техники безопасности и разумном распределении рабочего времени.
Прирассмотрении вопросов охраны труда большое внимание уделяется производственномуосвещению, оздоровлению воздушной среды, защите от шума, электробезопасности,пожарной безопасности и др.
Инженервсегда обязан помнить, что первое условие научно-организованного труда состоитв том, чтобы обеспечить безопасность людей.
Впроцессе работы здоровью людей могут угрожать факторы, вызванныепреимущественно неправильной организацией работы либо несоблюдением техникибезопасности.
Повышеннуюутомляемость может вызвать повышенный уровень шума; высокий уровень излучениямониторов либо неконтрастность изображения на них могут привести, также кповышенной утомляемости либо ослаблению зрения. С целью избежания подобныхнедостатков возможно применение защитных экранов, обеспечение персоналамониторами по возможности с более низким уровнем радиации и надзор за качествомизображения на них.
Непосредственнуюопасность для жизни и здоровья людей представляют собой приборы и элементыоборудования, требующие для своей работы питания от сети с высоким напряжением.С целью избежания несчастных случаев при использовании человеком подобногооборудования либо контакте с ним, необходимо проведение среди персоналапредприятия инструктажей по технике безопасности, а также, соблюдение иконтроль соблюдения требований техники безопасности. Кроме того, уменьшитьвероятность несчастных случаев или аварий можно путем проведения некоторыхорганизационных и профилактических мер.
Эффективнымсредством профилактики несчастных случаев является наиболее удачноерасположение оборудования, использование, по возможности, приборов иоборудования с наиболее оптимальными конструктивными решениями. Важнымсредством обеспечения безопасности служит надежная изоляция токонесущих частей,кабелей, а также, заземление корпусов всех приборов и металлических частейоборудования.
/>/>/> 7.2 Рабочее место программиста
Стандартноеавтоматизированное рабочее место программиста имеет необходимые составные части:
системныйблок, включающий в себя основную аппаратную логику, обеспечивающую нормальноефункционирование компьютера;
монитор,являющийся основным средством вывода информации, через который выдаетсяподавляющее количество всей выводимой информации, даже с учетом распространениямультимедиа;
клавиатурукак основное средство ввода, хотя в последнее время стремительно увеличиваетсязначимость манипулятора типа «мышь»;
вышеупомянутыйманипулятор типа «мышь».
Иногдапрограммист имеет дело с дополнительными периферийными устройствами, такими какпринтер, модем, но гораздо реже, поэтому эти устройства не играют решающей ролив обеспечении экологической безопасности рабочего места программиста иисключены из дальнейшего рассмотрения.
Рабочиеместа программистов и операторов ПЭВМ располагаются в помещениях, подверженномвлиянию совокупности производственных факторов, оказывающих влияние на здоровьеи работоспособность человека в процессе труда.
/>/>7.3 Вредные факторы на рабочем месте программиста ипользователя ЭВМ
Дажеисправный компьютер постоянно оказывает вредное воздействие на организмчеловека, которое может причинить большой вред организму человека, еслипренебрегать эргономическими и экологическими требованиями. К вреднымпроизводственным факторам относятся побочное излучение в различных диапазонах,дополнительные шумы, возникающие при работе компьютера. Группа эргономическихфакторов включает в себя правильность расположения отдельных частей компьютера,цветовую гамму окружающей обстановки, правильно подобранную палитру интерфейсаприкладных программ. Работа с системой связана с воздействием следующихпоражающих факторов:
Поражениеэлектрическим током питающей сети.
Пожароопасность.
Излученияэкрана монитора.
Шум,возникающий при работе механических и электрических устройств системы.
Физическиеперегрузки (статические).
Психофизиологическиеперегрузки:
Утомление,связанное с монотонностью работы,
Перенапряжениезрительных анализаторов,
Умственноенапряжение,
Эмоциональныеперегрузки в большом коллективе.
Поражающиефакторы 1 и 2 не являются источниками постоянно действующей опасности. Ихбезопасность гарантируется тщательным соблюдением правил техники безопасностиэксплуатации системы. Каждый работающий должен ознакомиться с этими правилами,пройти соответствующий инструктаж и следить за соблюдением этих правил. Поражающиефакторы 3-6 являются постоянно действующими, возникающими при каждодневнойтекущей работе.
/> 7.4 Нерациональное освещение
Правильноспроектированное и выполненное производственное освещение обеспечиваетвозможность нормальной производственной деятельности. Сохранность зрениячеловека, состояние его центральной нервной системы и безопасность напроизводстве в значительной мере зависят от условий освещения.
Анализируяусловия работы программиста получаем следующие требования к производственномуосвещению:
наименьшаядопустимая освещенность от общего освещения составляет 200 лк;
приработе за компьютером желательно, чтобы освещенность рабочего места не превышала2/3 нормальной освещенности помещения;
экрандисплея не должен быть ориентирован в сторону источников света (окон,настольных ламп и т.п.); при размещении рабочего места рядом с окном угол междуэкраном дисплея и плоскостью окна должен составлять не менее 90 градусов (дляисключения бликов), прилегающую часть окна желательно зашторить;
неследует располагать дисплей непосредственно под источником освещения иливплотную с ним;
стенапозади дисплея должна быть освещена примерно так же, как и его экран;
яркостьдля блестящих поверхностей более 0.2 кв. м не должна превышать 500 кд/кв. м;
показательослепленности не должен превышать 40 единиц;
коэффициентпульсаций 10 — 20%.
Спецификаработы за ЭВМ, состоит в том, что работать приходится с так называемым самосветящимсяобъектом.
Свечениесо стороны экрана, а также частая смена заставок на экране при большойпродолжительности трудовой деятельности может отрицательно воздействовать назрение.
Такойрежим работы утомляет зрительные органы. Поэтому разработчику программногообеспечения следует учитывать этот фактор при проектировании программногообеспечения и его отладке за компьютером.
Дляобеспечения нормальной естественной освещенности, площадь оконных проемовдолжна быть не менее 25% площади пола.
Работу программистаза компьютером можно отнести к классу точных работ. Контрастность текста наэкране монитора является средней, фон светлый. Следовательно рекомендуемаяосвещенность при работе с дисплеем составляет 200 лк.
Рекомендуемыеперепады яркости в поле зрения оператора должны лежать в пределах 1: 5 — 1: 10.
/> 7.5 Расчет общего освещения
Рассчитаемобщее освещение в машинном зале ПЭВМ методом коэффициента использованиясветового потока по уравнению:
Выбираемрекомендованное для машинного зала люминесцентное освещение.
/>
Располагаемсветильники рядами вдоль длинной стороны помещения. Будем использоватьсветильники типа УСП-35 с двумя лампами типа ЛБ-40.
Дляобеспечения наилучших условий освещения, расстояние между рядами светильников Lдолжно соответствовать отношению:

/>
гдеh-высота подвеса светильников,
где H = 3.2м — высота помещения,
hc = 0.2м — свес светильника,
hp = 0.75м — высота рабочей поверхности от пола.
/>
h = 3.0-0.2-0.75= 2.25 [м]
Þ L = λ*h = 3.1…3.4 [м]
Длинапомещения А = 8 м
Ширинапомещения В = 6 м
Количестворядов светильников N найдем из уравнения:
L * (0.33*2 + N-1) = B
/>
Количестворядов светильников N = 2 ряда.
Согласнонормам, нормируемая минимальная освещенность при общем освещении: Eн = 200 лк.
Так какзапыленность воздуха меньше 1 мг/м³, то коэффициент запаса:
Кз = 1.5
Площадьпомещения S = A*B = 8*6 = 48 [м²].
Так какмы предполагаем создать достаточно равномерное освещение, то коэффициентнеравномерности освещения: z = 1.15.
Индекспомещения:

/>
Коэффициентыотражения светового потока принимаем:
отпотолкаρп = 70%,
отстенρс = 50%,
отполаρпола = 10%.
Тогда потаблице находим коэффициент использования светового потока:
η =0.46.
Так какзатенения предполагаем не создавать, то коэффициент затенения:
γ =1.
Потаблице находим световой поток лампы ЛБ-40:
Фл = 3120лм.
Световойпоток светильника: Фсв = 2*Фл = 6240 [лм].
Количествосветильников в одном ряду:
/>
Расположениесветильников:
Длинасветильника lсв = 1.3 м
Количествосветильников в ряду М = 3 шт
Количестворядов светильников N = 2 шт
Так как А- М*lсв = 4.1
(где L — рассчитанное минимальное расстояние между светильниками), то расстояние междусветильниками в одном ряду L2 можно сделать равным расстоянию от крайнегосветильника в ряду до стены.
Тогда
/>
Расстояниемежду рядами L1 при расстоянии крайнего ряда от стены 0.33*L1:
/>
Итак, длянормального освещения машинного зала ПЭВМ используем 6 светильников типа УСП-35с двумя лампами типа ЛБ-40.
/> 7.6 Электроопасность
Помещениемашинного зала ПЭВМ не должно относится к категории помещений с повышеннойэлектроопасностью, то есть:
Относительнаявлажность воздуха в помещении должна быть не более 75%.
Должнаотсутствовать токопроводящая пыль.
Не должнобыть повышенной температуры воздуха в помещении (температура постоянно илипериодически, более одних суток, превышает +35 ºС).
Должнаотсутствовать возможность одновременного прикосновения человека к имеющимсоединение с землей металлическим конструкциям здания, оборудованию и т.д., содной стороны, и к металлическим корпусам аппаратуры или токоведущим частям, сдругой стороны.
Не должнобыть токопроводящих полов.
Основнымисредствами защиты от поражения электрическим током при работе на компьютереявляются защитное заземление и зануление.
Защитноезаземление — это преднамеренное электрическое соединение с землей или ееэквивалентом металлических нетоковедущих частей электрического итехнологического оборудования, которые могут оказаться под напряжением. Защитноезаземление является простым, эффективным и широко распространенным способомзащиты человека от поражения электрическим током при прикосновении кметаллическим поверхностям, оказавшимся под напряжением. Обеспечивается этоснижением напряжения между оборудованием, оказавшимся под напряжением, и землейдо безопасной величины.
Опасностьприкосновения человека к токоведущим частям электроустановки определяетсявеличиной протекающего через тело человека тока. В общем случае величина этоготока зависит от схемы прикосновения человека к электросети, ее напряжения,схемы самой сети и рода тока, режима нейтрали сети. Для питания отдельныхустройств используются однофазные сети переменного тока 220 В / 50 Гц.
Iраб. = Upaб. / R,где
Upaб. — рабочее напряжение сети;
R — электрическое сопротивление тела человека.
Iраб. = 220В / 1000Ом = 0,22А — ток, протекающий через телочеловека.
Iпор. = 0,5 мА — допустимая величина тока.
Как видноиз приведенной формулы, сила тока, протекающего через тело человека, зависиттолько от напряжения сети и сопротивления человека. В этом случае единственноймерой, повышающей безопасность обслуживающего персонала, может быть понижениерабочего напряжения сети. Однако по техническим условиям напряжение питанияустройств в машинном зале составляет 220В.
Какпоказывает анализ случаев электротравматизма при эксплуатации промышленныхустановок, чаще всего имеет место однополюсное (однофазное) прикосновение визолированных и глухозаземленных сетях.
Единственнымфактором, при данном напряжении, ограничивающим силу тока протекающего черезтело человека в однофазных сетях, является сопротивление тела человека.
Опасностьэксплуатации таких электроустановок очевидна. Эффективной мерой защиты припитании оборудования машинного зала напряжением опасным для жизни человекаявляется защитное заземление. Заземляющим устройством называют совокупностьзаземлителя (металлического проводника или группы проводников, находящихся внепосредственном соприкосновении с грунтом) и заземляющих проводников,соединяющих заземленные части электроустановки с заземлителем. Если корпусэлектрооборудования не имеет контакта с землей, то в случае перехода напряженияприкосновение к нему так же опасно, как и прикосновение к токоведущим частямэлектроустановки. Когда корпус заземляют, образуется ветвь тока, параллельнаяучастку сети, в которую включается человек. Ток замыкания на землюперераспределяется: вследствие малого сопротивления заземляющего устройства — большийток пойдет через заземляющую систему, и меньший — через человека. При исправномзаземлении ток, проходящий через тело человека, становится неопасным.Т. к. помещениемашинного зала относится к классу помещений без повышенной опасности, то дляобеспечения безопасности персонала необходим обычный комплекс профилактическихработ, включающий обеспечение надежного заземления всех металлических частей,причем наибольшая допустимая величина сопротивления заземления не должнапревышать 4 Ом.
Занулениеявляется одним из средств, обеспечивающих безопасную эксплуатациюэлектроустановок. Оно выполняется присоединением к неоднократно заземленномунулевому проводу корпусов и других конструктивных металлических частейэлектрооборудования, которые нормально не находятся под напряжением, но могутоказаться под ним при повреждении изоляции.
Наибольшеедопустимое сопротивление заземляющих устройств и заземлителей в системезануления при подключении ЭВМ типа IBM PC составляет 30 Ом.
Изоляцияимеет важное значение в электроустановках, она защищает их от чрезмерной утечкитоков, предохраняет людей от поражения током и исключает возникновение пожаров.
Правиламиустройства электроустановок определено, что сопротивление изоляции сети научастке между двумя смежными предохранителями или за последнимипредохранителями между любыми проводами должно быть не менее 0.5 МОм.
Проводкав производственных помещениях выполняется изолированными проводами иликабелями, которые в местах, где возможны их механические повреждения,укладываются в металлические трубы. Помещения, в которых устанавливаютсяперсональные ЭВМ должны соответствовать всем вышеуказанным требованиям.
/> 7.7 Требования по пожарной безопасности
Помещениемашинного зала ПЭВМ относится к категории В (пожароопасная) пожарной опасностипомещений, так как в помещении находится электрооборудование, горючие вещества(мебель, пластиковые корпуса аппаратуры и др.). Поэтому помещение должносоответствовать нормативам по огнестойкости строительных конструкций,планировке зданий, этажности, оснащенности устройствами противопожарной защиты,установленным для этой категории помещений. Помещение машинного зала должнообладать I или II степенью огнестойкости (см. СНиП 2.01.02-85 “Противопожарныенормы”), то есть самой высокой.
/> 
7.8 Меры по снижению уровня шума
Шумоказывает большое влияние на человека и его работоспособность. Уже при уровняхшума в 40-70 дБ ослабляется внимание, ухудшается память, появляется быстраяутомляемость, головная боль. Наибольшей степенью воздействия на состояниечеловека обладают импульсные и нерегулярные шумы.
СогласноГОСТ 12.1 003-83 ССБТ “Шум. Общие требования безопасности” допустимым значениемуровня шума в помещении машинного зала ПЭВМ является 50 дБ. Основнымиисточниками шума в помещении машинного зала являются матричные принтеры,которые могут создавать уровень шума близкий к 50 дБ. Для снижения уровня шумав помещении машинного зала рекомендуется:
Располагатьпомещение машинного зала вдали от внешних источников шума.
Использоватьзвукопоглощающие облицовочные материалы.
Использоватьмалошумящую вентиляцию.
Использоватьструйные или лазерные принтеры вместо матричных.
/> 7.9 Защита от вредных излучений
Основнымисточником эргономических проблем, связанных с охраной здоровья людей,использующих в своей работе персональные компьютеры, являются дисплеи (мониторы),особенно дисплеи с электронно-лучевыми трубками. Они представляют собойисточники наиболее вредных излучений, неблагоприятно влияющих на здоровьеоператоров.
Историяисследования этого вопроса достаточно длительная и непростая, но полученныерезультаты носят пока еще преимущественно статистический характер и не имеютадекватного объяснения. Частотный состав (спектр) излучения мониторахарактеризуется наличием рентгеновских, ультрафиолетовых, инфракрасных и другихэлектромагнитных колебаний. Опасность рентгеновского и части других излученийбольшинством ученых признается пренебрежимо малой, поскольку их уровеньдостаточно невелик и в основном поглощается покрытием экрана. Наиболее тяжелаяситуация связана, по-видимому, с полями излучений очень низких частот (ОНЧ) икрайне низких частот (КНЧ), которые, как выяснилось, способны вызыватьбиологические эффекты при воздействии на живые организмы. Было обнаружено, чтоэлектромагнитные поля с частотой порядка 60 Гц могут инициировать изменения вклетках животных (вплоть до нарушения синтеза ДНК). Особенно поразительным дляисследователей оказался тот факт, что, в отличие, например, от рентгеновскогоизлучения, электромагнитные волны обладают необычным свойством: опасность ихвоздействия при снижении интенсивности излучения не уменьшается, мало того,некоторые поля действуют на клетки тела только при малых интенсивностях или наконкретных частотах.
Специальныеизмерения показали, что мониторы действительно излучают магнитные волны, поинтенсивности не уступающие уровням магнитных полей, способных обусловливатьвозникновение опухолей у людей.
Исследователииз Macworld обнаружили, что если на расстоянии 10 см перед мониторами, обычноиспользуемыми с компьютерами Macintosh, напряженность магнитного полясоставляет примерно от 5 до 23 мГс, то на расстоянии 70 см от экрана ни уодного из обследованных мониторов напряженность поля не превышала величины 1мГс. (Интенсивность поля вне указанных пределов составляла 0.1 — 0.5 мГс)
Как этони странно, но до сих пор нет нормативов для излучений КНЧ-магнитных полей,хотя в некоторых странах (в том числе в Швеции и Канаде) разработаны стандартыдля излучений ОНЧ-магнитных полей. Большое число поставщиков — например, фирмыIBM, DEC и Philips — продают мониторы, удовлетворяющие указанным стандартам. Крометого, любой монитор, работающий не на ЭЛТ, имеет то преимущество, что неизлучает переменных компонент, связанных с наличием систем вертикального игоризонтального отклонения электронного луча.
Пользователямперсональных компьютеров, желающим снизить уровень облучения переменнымимагнитными полями, следует расположить мониторы так, чтобы расстояние до нихсоставляло величину, равную расстоянию вытянутой руки (с вытянутыми пальцами). Посколькумагнитные поля сзади и по бокам большинства мониторов значительно сильнее, чемперед экраном, пользователи должны располагать свои рабочие места на расстояниине менее 1.22 м от боковых и задних стенок других компьютеров. Следует иметьввиду, что магнитное излучение ничем не задерживается.
/> 7.10 Параметры микроклимата в машинном зале
Метеорологическимиусловиями согласно ГОСТ 12.1 005-88 являются:
температура;
относительнаявлажность;
скоростьдвижения воздуха;
атмосферноедавление.
С цельюобеспечения комфортных условий для операторов ПЭВМ и надежной работыоборудования, необходимо поддерживать следующие метеорологические условия (согласноСН 512-78):
Атмосферноедавление в помещении машинного зала должно быть 1013.25±266 ГПа. При пониженномдавлении воздуха ухудшается отвод теплоты от элементов ПЭВМ, снижаютсяизоляционные свойства воздуха.
Воздух,используемый для вентиляции машинного зала, должен очищаться от пыли. Запыленностьвоздуха не должна превышать 1 мг/м³, а размеры пылинок — 3 мкм.
Пыль,попадающая на платы комплекса, приводит к снижению теплообмена и способствуетперегреву приборов.
Впомещении машинного зала необходимо предусмотреть систему отопления.
Онадолжна обеспечивать достаточное, постоянное и равномерное нагревание воздуха впомещении в холодный период года, а также безопасность в отношении пожара ивзрыва. При этом колебания температуры в течении суток не должны превышать 2-3°С; в горизонтальном направлении — 2 °С на каждый метр длины; а в вертикальном — 1 °С на каждый метр высоты помещения.
Дляотопления помещения машинного зала рекомендуется использовать водяные иливоздушные системы центрального отопления.
Работающиелюди и включенные компьютеры являются источниками избыточного тепла в помещениимашинного зала.
Поэтомунеобходимо предусмотреть систему кондиционирования помещения.
Таблица 5.Параметры воздушной среды Параметры воздушной среды на рабочих местах Темпера-тура Оптимальные Допустимые Наружного воздуха, °С Темпера-тура, °С Относитель-ная влажность,% Скорость движения воздуха, не более, м/c Темпера-тура, °С Относитель-ная влажность,% Скорость движения воздуха, не более, м/c Ниже +10 20-22 40-60 0.2 18-22 Не более 70 0.3 Выше +10 20-25 40-60 0.3 Не более, чем на 3 °С выше наружного воздуха в 13 ч дня самого жаркого месяца, но не выше 28 °С
70 при 24 °С
и ниже;
65 при 25 °С;
60 при 26 °С;
55 при 27 °С;
50 при 28 °С. 0.5
/>/>7.11 Психофизиологические факторы
Психофизиологическиефакторы в зависимости от характера действия делятся на следующие группы:
физическиеперегрузки (статические);
нервно-психическиеперегрузки:
умственноеперенапряжение,
перенапряжениезрительных анализаторов,
монотонностьтруда,
эмоциональныеперегрузки в большом коллективе.
Монотонностьили монотония — психическое состояние человека, вызванное однообразиемвосприятий или действий. Под утомлением понимается процесс пониженияработоспособности, временный упадок сил, возникающий при выполненииопределенной физической или умственной работы. Для уменьшения влияния этихфакторов необходимо применять оптимальные режимы труда и отдыха в течениирабочего дня:
общеевремя работы за дисплеем не должно превышать 50% всего рабочего временипрограммиста;
приобычной работе за компьютером необходимо делать 15-минутные перерывы через каждыедва часа, а при интенсивной работе — через каждый час;
неследует превышать темп работы порядка 10 тысяч нажатий клавиш в час (примерно1500 слов);
предпочтительнееиспользовать дисплеи с высокой разрешающей способностью (разрешением) и удобнымразмером экрана (лучше не применять CGA-мониторы и малоразмерные, менее 14"по диагонали, экраны);
лучшевыбирать видеоадаптеры с высоким разрешением и, по возможности (если есть нарынке и цена приемлемая), частотой обновления экранного изображения не менее70-72 Гц;
обязательноставить на дисплеи экранные, в частности, поляризационные, фильтры, в несколькораз снижающие утомляемость глаз;
наконец,при вводе данных с клавиатуры рекомендуется не зажимать телефонную трубку междуплечом и ухом.
Рабочаяпоза оказывает значительное влияние на эффективность работы человека. Основныетребования к рабочим местам при выполнении работы сидя приведены в ГОСТ 12.2 033-78«ССБТ. Рабочее место при выполнении работ сидя. Общие эргономическиетребования». При организации рабочего места программиста необходимопридерживаться следующих рекомендаций:
рабочееместо должно быть оборудовано так, чтобы исключать неудобные позы и длительныестатические напряжения тела;
посколькунайти такое идеальное положение для тела, в котором можно было бы пребывать втечении всего дня, вряд ли возможно, для большинства людей комфортабельнымможет быть рабочее место, которое можно приспособить, как минимум, для двухпозиций (при этом положение оборудования должно соответствовать выполняемойработе и привычкам пользователя).
Кобслуживанию и работе на ЭВМ допускаются лица прошедшие медосмотр припоступлении на работу. Последующий медосмотр проводится раз в два года. Такженеобходимо соблюдать ограничения на работу с персональными компьютерами дляслужащих, страдающих заболеваниями опорно-двигательного аппарата, глаз (илинарушениями зрения), кожи./> 7.12 Планировка рабочего места программиста иорганизация работы с компьютером
Планировкарабочего места программиста должна удовлетворять требованиям удобствавыполнения работы и экономии энергии и времени программиста, рациональногоиспользования площади помещения, соблюдения правил охраны труда. Рекомендуемаяпланировка рабочего места программиста, учитывающая антропометрические данныечеловека и габариты аппаратуры представлена на Рис.28.
/>
Рис.28. Рекомендуемаяпланировка рабочего места программиста.
Дляоблегчения чтения информации с документов рекомендуется использоватьспециальные держатели бумаг, крепящиеся к монитору компьютера. Дляпредотвращения перенапряжения зрительных анализаторов оператора и снижениямонотонности труда, работу, связанную с использованием дисплея ПЭВМ, необходимочередовать с работой, не требующей использования ПЭВМ, либо делать небольшиеперерывы через каждые 45-90 минут. Общее время работы за экраном ЭВМ не должнопревышать 6 часов в день.
/> 7.13 Выводы
В этойглаве дипломного проекта рассмотрены требования охраны труда и разработанырекомендации по оптимизации санитарно-гигиенической обстановки при выполненииработ на ЭВМ.
В даннойглаве были рассмотрены вопросы:
Нерациональностьосвещения
Излученияэкрана монитора
Электроопасность
Шум
Параметрымикроклимата
Психофизиологическиеперегрузки.
Установлено,что уровень шума на рабочем месте не должен превышать 50 дб, объем производственногопомещения на одного работающего должен составлять не менее 15 куб. м, площадь — не менее 4.5 кв. м, наименьшая допустимая освещенность — 200 лк.
Показанаважность и необходимость организационных и санитарно-профилактическихмероприятий по созданию условий безопасного труда.
В даннойглаве был проведен расчет искусственного освещения и подсчитано фактическоезначение минимальной освещенности дисплейного класса — 200 лк.
Вопросыэкологической безопасности не рассматривались, поскольку работа с ЭВМ несвязана с использованием природных ресурсов, нет вредных выбросов в окружающуюсреду и не представляет опасности для окружающей среды.
/>/>Заключение
Такимобразом, в результате проведенных работ намечены пути построениякомпьютерно-сетевой системы управления производственным процессом предприятияэлектронной промышленности. В частности, было проанализировано текущеесостояние производственного процесса, проанализированы известные методысоздания аналогичных систем управления и разработаны предложения попроектированию системы управления производством партий на ОАО «Ангстрем».
Дальнейшиеэтапы работы должны состоять в следующем:
созданиеимитационной программы, моделирующей процесс управления производством партий;
разработкаалгоритмов дисциплины очереди;
проектированиесистемы управления;
реализация,тестирование и оптимизация системы управления производством партий на ОАО«Ангстрем».
Необходимоподчеркнуть, что разработка компьютерно-сетевых систем управленияпроизводственными процессами весьма актуальна для отечественной промышленности.И возможно, разрабатываемая АСУ ПП станет базовым образцом для широкого класса«интеллектуальных» промышленных систем управления.
/>/>Список использованной литературы
1.        Поспелов Д.А. Ситуационное управление. Теория и практика. М.: Наука,1986, 285 с.
2.        Поспелов Д.А. Принципы ситуационного управления // Известия АН СССР. СерияТехническая кибернетика. 1971. N.2.
3.        Клыков Ю.И. Ситуационное управление большими системами. М.: Энергия,1974.
4.        Поспелов Д.А. Большие системы. Ситуационное управление. М.: Знание, 1975.
5.        Искусственный интеллект. — В 3-х кн. Справочник. М.: Радио и связь, 1990.
6.        MES Explained: A High Level Vision for Executives. WhitePaper of MESA International (1997). Интернет-адрес: www.mesa.org/html/main. cgi? sub=7
7.        Technical Articles of Consilium Company. Интернет-адрес:www.consilium.com/Publications/technica. htm
8.        Уоссермен Ф. Нейрокомпьютерная техника. Теория и практика. М.: Мир, 1992.238с.
9.        С.С. Гайсарян. Объектно-ориентированные технологии проектированияприкладных программных систем. Интернет-адрес: www.citforum.ru/programming/oop_rsis/index. shtml
10.      P. Coad, M. Mayfield. Object Models: Strategies,Patterns and Applications (Yourdon Press Computing Series). 1996.
11.      Буч.Г. «Объектно-ориентированный анализ и проектирование спримерами приложений на C++», М.,«Бином»,1998 г.
/>/>Приложение
Фрагментыисходного кода
 // Angstrem. h: main header file for the ANGSTREM application
 //
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#ifndef __AFXWIN_H__
#error include 'stdafx. h' before including this file for PCH
#endif
#include «resource. h» // main symbols
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CAngstremApp:
 // See Angstrem. cpp for the implementation of this class
 //
class CAngstremApp: public CWinApp
{
public:
CAngstremApp ();
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CAngstremApp)
public:
virtual BOOL InitInstance ();
 // }}AFX_VIRTUAL
 // Implementation
 // {{AFX_MSG (CAngstremApp)
afx_msg void OnAppAbout ();
afx_msg void OnObjectsPartsNew ();
afx_msg void OnObjectsPartsOpen ();
afx_msg void OnObjectsPartsViewall ();
afx_msg void OnObjectsPartsDelete ();
afx_msg void OnAppFindpart ();
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // {{AFX_INSERT_LOCATION}}
 // Microsoft Visual C++ will insert additional declarationsimmediately before the previous line.
 // Angstrem. cpp: Defines the class behaviors for the application.
 //
#include «stdafx. h»
#include «Angstrem. h»
#include «MainFrame. h»
#include «ChildFrame. h»
#include «AngstremDoc. h»
#include «AngstremView. h»
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE [] = __FILE__;
#endif
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CAngstremApp
BEGIN_MESSAGE_MAP (CAngstremApp, CWinApp)
 // {{AFX_MSG_MAP (CAngstremApp)
ON_COMMAND (ID_APP_ABOUT, OnAppAbout)
ON_COMMAND (ID_OBJECTS_PARTS_NEW, OnObjectsPartsNew)
ON_COMMAND (ID_OBJECTS_PARTS_OPEN, OnObjectsPartsOpen)
ON_COMMAND (ID_OBJECTS_PARTS_VIEWALL, OnObjectsPartsViewall)
ON_COMMAND (ID_OBJECTS_PARTS_DELETE, OnObjectsPartsDelete)
ON_COMMAND (ID_APP_FINDPART, OnAppFindpart)
 // }}AFX_MSG_MAP
 // Standard file based document commands
END_MESSAGE_MAP ()
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CAngstremApp construction
CAngstremApp:: CAngstremApp ()
{
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // The one and only CAngstremApp object
CAngstremApp theApp;
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CAngstremApp initialization
BOOL CAngstremApp:: InitInstance ()
{
 // Standard initialization
 // If you are not using these features and wish to reduce the size
 // of your final executable, you should remove from the following
 // the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls (); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic (); // Call this when linking to MFCstatically
#endif
 // Change the registry key under which our settings are stored.
 // TODO: You should modify this string to be something appropriate
 // such as the name of your company or organization.
SetRegistryKey (_T («Local AppWizard-Generated Applications»));
LoadStdProfileSettings (); // Load standard INI file options (includingMRU)
 // Register the application's document templates. Document templates
 // serve as the connection between documents, frame windows andviews.
CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate (
IDR_ANGSTRTYPE,
RUNTIME_CLASS (CAngstremDoc),
RUNTIME_CLASS (CChildFrame), // custom MDI child frame
RUNTIME_CLASS (CAngstremView));
AddDocTemplate (pDocTemplate);
 // create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (! pMainFrame->LoadFrame (IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;
 // Enable drag/drop open
m_pMainWnd->DragAcceptFiles ();
 // Enable DDE Execute open
EnableShellOpen ();
RegisterShellFileTypes (TRUE);
 // Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine (cmdInfo);
 // Dispatch commands specified on the command line
if (! ProcessShellCommand (cmdInfo))
return FALSE;
 // The main window has been initialized, so show and update it.
pMainFrame->ShowWindow (m_nCmdShow);
pMainFrame->UpdateWindow ();
return TRUE;
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CAboutDlg dialog used for App About
class CAboutDlg: public CDialog
{
public:
CAboutDlg ();
 // Dialog Data
 // {{AFX_DATA (CAboutDlg)
enum { IDD = IDD_ABOUTBOX };
 // }}AFX_DATA
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CAboutDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // {{AFX_MSG (CAboutDlg)
 // No message handlers
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
CAboutDlg:: CAboutDlg (): CDialog (CAboutDlg:: IDD)
{
 // {{AFX_DATA_INIT (CAboutDlg)
 // }}AFX_DATA_INIT
}
void CAboutDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CAboutDlg)
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CAboutDlg, CDialog)
 // {{AFX_MSG_MAP (CAboutDlg)
 // No message handlers
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
 // App command to run the dialog
void CAngstremApp:: OnAppAbout ()
{
CAboutDlg aboutDlg;
aboutDlg. DoModal ();
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CNewPartDlg dialog
class CNewPartDlg: public CDialog
{
 // Construction
public:
CNewPartDlg (CWnd* pParent = NULL); // standard constructor
 // Dialog Data
 // {{AFX_DATA (CNewPartDlg)
enum { IDD = IDD_PARTNEW };
 // NOTE: the ClassWizard will add data members here
 // }}AFX_DATA
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CNewPartDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CNewPartDlg)
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
CNewPartDlg:: CNewPartDlg (CWnd* pParent /*=NULL*/)
: CDialog (CNewPartDlg:: IDD, pParent)
{
 // {{AFX_DATA_INIT (CNewPartDlg)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
void CNewPartDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CNewPartDlg)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CNewPartDlg, CDialog)
 // {{AFX_MSG_MAP (CNewPartDlg)
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
void CAngstremApp:: OnObjectsPartsNew ()
{
 // TODO: Add your command handler code here
CNewPartDlg newPartDlg;
newPartDlg. DoModal ();
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // COpenPartDlg dialog
class COpenPartDlg: public CDialog
{
 // Construction
public:
COpenPartDlg (CWnd* pParent = NULL); // standard constructor
 // Dialog Data
 // {{AFX_DATA (COpenPartDlg)
enum { IDD = IDD_PARTOPEN };
 // NOTE: the ClassWizard will add data members here
 // }}AFX_DATA
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (COpenPartDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (COpenPartDlg)
 // NOTE: the ClassWizard will add member functions here
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
COpenPartDlg:: COpenPartDlg (CWnd* pParent /*=NULL*/)
: CDialog (COpenPartDlg:: IDD, pParent)
{
 // {{AFX_DATA_INIT (COpenPartDlg)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
void COpenPartDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (COpenPartDlg)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (COpenPartDlg, CDialog)
 // {{AFX_MSG_MAP (COpenPartDlg)
 // NOTE: the ClassWizard will add message map macros here
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
void CAngstremApp:: OnObjectsPartsOpen ()
{
 // TODO: Add your command handler code here
COpenPartDlg openPartDlg;
openPartDlg. DoModal ();
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CViewAllPartsDlg dialog
class CViewAllPartsDlg: public CDialog
{
 // Construction
public:
CViewAllPartsDlg (CWnd* pParent = NULL); // standard constructor
 // Dialog Data
 // {{AFX_DATA (CViewAllPartsDlg)
enum { IDD = IDD_PARTSVIEWALL };
 // NOTE: the ClassWizard will add data members here
 // }}AFX_DATA
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CViewAllPartsDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CViewAllPartsDlg)
 // NOTE: the ClassWizard will add member functions here
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
CViewAllPartsDlg:: CViewAllPartsDlg (CWnd* pParent /*=NULL*/)
: CDialog (CViewAllPartsDlg:: IDD, pParent)
{
 // {{AFX_DATA_INIT (CViewAllPartsDlg)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
void CViewAllPartsDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CViewAllPartsDlg)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CViewAllPartsDlg, CDialog)
 // {{AFX_MSG_MAP (CViewAllPartsDlg)
 // NOTE: the ClassWizard will add message map macros here
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
void CAngstremApp:: OnObjectsPartsViewall ()
{
 // TODO: Add your command handler code here
CViewAllPartsDlg viewAllPartsDlg;
viewAllPartsDlg. DoModal ();
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CDeletePartDlg dialog
class CDeletePartDlg: public CDialog
{
 // Construction
public:
CDeletePartDlg (CWnd* pParent = NULL); // standard constructor
 // Dialog Data
 // {{AFX_DATA (CDeletePartDlg)
enum { IDD = IDD_PARTDELETE };
 // NOTE: the ClassWizard will add data members here
 // }}AFX_DATA
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CDeletePartDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CDeletePartDlg)
 // NOTE: the ClassWizard will add member functions here
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
CDeletePartDlg:: CDeletePartDlg (CWnd* pParent /*=NULL*/)
: CDialog (CDeletePartDlg:: IDD, pParent)
{
 // {{AFX_DATA_INIT (CDeletePartDlg)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
void CDeletePartDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CDeletePartDlg)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CDeletePartDlg, CDialog)
 // {{AFX_MSG_MAP (CDeletePartDlg)
 // NOTE: the ClassWizard will add message map macros here
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
void CAngstremApp:: OnObjectsPartsDelete ()
{
 // TODO: Add your command handler code here
CDeletePartDlg deletePartDlg;
deletePartDlg. DoModal ();
}
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CPartProcessingPage dialog
class CPartProcessingPage: public CPropertyPage
{
DECLARE_DYNCREATE (CPartProcessingPage)
 // Construction
public:
CPartProcessingPage ();
~CPartProcessingPage ();
 // Dialog Data
 // {{AFX_DATA (CPartProcessingPage)
enum { IDD = IDD_PART_PROCESSING };
 // NOTE — ClassWizard will add data members here.
 // DO NOT EDIT what you see in these blocks of generated code!
 // }}AFX_DATA
 // Overrides
 // ClassWizard generate virtual function overrides
 // {{AFX_VIRTUAL (CPartProcessingPage)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CPartProcessingPage)
afx_msg void OnRefresh ();
afx_msg void OnStart ();
afx_msg void OnFinish ();
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
IMPLEMENT_DYNCREATE (CPartProcessingPage, CPropertyPage)
CPartProcessingPage:: CPartProcessingPage (): CPropertyPage (CPartProcessingPage::IDD)
{
 // {{AFX_DATA_INIT (CPartProcessingPage)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
CPartProcessingPage:: ~CPartProcessingPage ()
{
}
void CPartProcessingPage:: DoDataExchange (CDataExchange* pDX)
{
CPropertyPage:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CPartProcessingPage)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CPartProcessingPage, CPropertyPage)
 // {{AFX_MSG_MAP (CPartProcessingPage)
ON_BN_CLICKED (IDREFRESH, OnRefresh)
ON_BN_CLICKED (IDC_START, OnStart)
ON_BN_CLICKED (IDC_FINISH, OnFinish)
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CPartProcessingsPage dialog
class CPartProcessingsPage: public CPropertyPage
{
DECLARE_DYNCREATE (CPartProcessingsPage)
 // Construction
public:
CPartProcessingsPage ();
~CPartProcessingsPage ();
 // Dialog Data
 // {{AFX_DATA (CPartProcessingsPage)
enum { IDD = IDD_PART_PROCESSINGS };
 // NOTE — ClassWizard will add data members here.
 // DO NOT EDIT what you see in these blocks of generated code!
 // }}AFX_DATA
 // Overrides
 // ClassWizard generate virtual function overrides
 // {{AFX_VIRTUAL (CPartProcessingsPage)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CPartProcessingsPage)
 // NOTE: the ClassWizard will add member functions here
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
IMPLEMENT_DYNCREATE (CPartProcessingsPage, CPropertyPage)
CPartProcessingsPage:: CPartProcessingsPage (): CPropertyPage (CPartProcessingsPage::IDD)
{
 // {{AFX_DATA_INIT (CPartProcessingsPage)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
CPartProcessingsPage:: ~CPartProcessingsPage ()
{
}
void CPartProcessingsPage:: DoDataExchange (CDataExchange* pDX)
{
CPropertyPage:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CPartProcessingsPage)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CPartProcessingsPage, CPropertyPage)
 // {{AFX_MSG_MAP (CPartProcessingsPage)
 // NOTE: the ClassWizard will add message map macros here
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CPartRoutePage dialog
class CPartRoutePage: public CPropertyPage
{
DECLARE_DYNCREATE (CPartRoutePage)
 // Construction
public:
CPartRoutePage ();
~CPartRoutePage ();
 // Dialog Data
 // {{AFX_DATA (CPartRoutePage)
enum { IDD = IDD_PART_ROUTE };
 // NOTE — ClassWizard will add data members here.
 // DO NOT EDIT what you see in these blocks of generated code!
 // }}AFX_DATA
 // Overrides
 // ClassWizard generate virtual function overrides
 // {{AFX_VIRTUAL (CPartRoutePage)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CPartRoutePage)
 // NOTE: the ClassWizard will add member functions here
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
IMPLEMENT_DYNCREATE (CPartRoutePage, CPropertyPage)
CPartRoutePage:: CPartRoutePage (): CPropertyPage (CPartRoutePage:: IDD)
{
 // {{AFX_DATA_INIT (CPartRoutePage)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
CPartRoutePage:: ~CPartRoutePage ()
{
}
void CPartRoutePage:: DoDataExchange (CDataExchange* pDX)
{
CPropertyPage:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CPartRoutePage)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CPartRoutePage, CPropertyPage)
 // {{AFX_MSG_MAP (CPartRoutePage)
 // NOTE: the ClassWizard will add message map macros here
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
 // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // // // // // // // // /
 // CFindPartDlg dialog
class CFindPartDlg: public CDialog
{
 // Construction
public:
CFindPartDlg (CWnd* pParent = NULL); // standard constructor
 // Dialog Data
 // {{AFX_DATA (CFindPartDlg)
enum { IDD = IDD_FINDPART };
 // NOTE: the ClassWizard will add data members here
 // }}AFX_DATA
 // Overrides
 // ClassWizard generated virtual function overrides
 // {{AFX_VIRTUAL (CFindPartDlg)
protected:
virtual void DoDataExchange (CDataExchange* pDX); // DDX/DDV support
 // }}AFX_VIRTUAL
 // Implementation
protected:
 // Generated message map functions
 // {{AFX_MSG (CFindPartDlg)
virtual void OnOK ();
 // }}AFX_MSG
DECLARE_MESSAGE_MAP ()
};
CFindPartDlg:: CFindPartDlg (CWnd* pParent /*=NULL*/)
: CDialog (CFindPartDlg:: IDD, pParent)
{
 // {{AFX_DATA_INIT (CFindPartDlg)
 // NOTE: the ClassWizard will add member initialization here
 // }}AFX_DATA_INIT
}
void CFindPartDlg:: DoDataExchange (CDataExchange* pDX)
{
CDialog:: DoDataExchange (pDX);
 // {{AFX_DATA_MAP (CFindPartDlg)
 // NOTE: the ClassWizard will add DDX and DDV calls here
 // }}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP (CFindPartDlg, CDialog)
 // {{AFX_MSG_MAP (CFindPartDlg)
 // }}AFX_MSG_MAP
END_MESSAGE_MAP ()
void CFindPartDlg:: OnOK ()
{
 // TODO:Add extra validation here
 // считываниеномера партии и изделия в
 // видимыедля PartSheet переменные
CDialog::OnOK ();
}
void CAngstremApp:: OnAppFindpart ()
{
 // TODO: Add your command handler code here
INT partNumber;
INT productNumber;
CFindPartDlg findPartDlg;
if (findPartDlg.DoModal () == IDOK)
{
 // Созданиеобъекта блока диалога с вкладками
CPropertySheetpartSheet («Part»);
 // Созданиеобъекта для каждой вкладки
CPartProcessingPage partProcessingPage;
CPartProcessingsPage partProcessingsPage;
CPartRoutePage partRoutePage;
 // Добавление вкладок в блок диалога
partSheet. AddPage (&partProcessingPage);
partSheet. AddPage (&partProcessingsPage);
partSheet. AddPage (&partRoutePage);
partSheet. DoModal ();
}
}
 // // //// // // // // // // // // // // // // // // // // // // // // // // // // //// // // // // // // // // /