Дипломная работа: Разработка программы контроллера автоматически связываемых объектов для управления конструкторской документацией в среде Windows 95/NT (дипломная работа)

Дипломная работа: Разработка программы контроллера автоматически связываемых объектов для управления конструкторской документацией в среде Windows 95/NT (дипломная работа)

УДК 681.3.069:(389.6:744(083.74)

Сорокин Ю.В. Разработка программы контроллера автоматически связываемых объектов для управления конструкторской документацией в среде Windows 95/NT. Дипломная работа. - Таганрог, 1997. - с.

АННОТАЦИЯ

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

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

Перечень графической документации

Цтрк 5.035.014СБ Плата УИ. Сборочный чертеж - формат А1

Цтрк 7.035.014     Печатная плата - формат А1

УДК 681.3.069:(389.6:744(083.74) Структурная схема контроллера автоматически связываемых объектов. Плакат - формат А1

УДК 681.3.069:(389.6:744(083.74) Функциональная схема работы операционной системы Windows 95. Плакат - формат А1

УДК 681.3.069:(389.6:744(083.74) Функциональная схема работы OLE и системы OLE Automation. Плакат - формат А1

УДК 681.3.069:(389.6:744(083.74) Функциональная схема работы блока выполнения функций OLE Automation. Плакат - формат А1

УДК 681.3.069:(389.6:744(083.74) Структура организации данных контроллера. Плакат - формат А1

УДК 681.3.069:(389.6:744(083.74) Безопасность и экологичность проекта. Плакат - формат А1

Введение

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

Компьютерные средства проектирования, кроме непосредственно компьютерного оборудования, включают в себя программное обеспе­чение. На нынешнем этапе развития программного обеспечения систем проектирования, имеется много разработок систем автоматизации про­ектирования. Рынок программного обеспечения насыщен большим ко­личеством разнообразных пакетов прикладных программ включающих в себя различные инструментальные средства, позволяющие во многом упростить работу конструктора ЭВА. Сейчас у нас в стране и за рубе­жом наиболее распространены такие пакеты программного обеспече­ния, как PCAD, AutoCAD, MicroCAPS, Pspice, MathCad и другие. Эти программные средства позволяют автоматизировать сложные и однообразные процессы присутствующие на многих этапах проектирования ЭВА. Например, различного рода математические расчеты всевозможной сложности, логическое моделирование схем, разработка топологии микросхем, разводка печатного монтажа печатной платы, создание готовых конструкторских документов высокого качества и т.д.

Рост популярности автоматизированных систем проектирования возник во многом благодаря улучшению пользовательского интерфейса программного обеспечения в целом и систем проектирования в частности. За последние несколько лет у разработчиков программного обеспечения все большие симпатии вызывает платформа Windows для создания высоко качественных программных продуктов предоставляющих пользователю наиболее удобный для восприятия интерфейс. Удобство интерфейса Windows обусловлено высокими требованиями с эргономической точки зрения предъявленному создателями Windows к своей операционной системе. Свою систему Windows фирма Microsoft создала для платформы IBM, не случайно. Надо отметить значительную популярность в мире компьютеров совместимых с IBM AT. Ставшей в наше время своеобразным мировым эталоном сочетания качества и низкой цены. Более половины компьютерного рынка принадлежит компьютерам совместимым с IBM AT.

Однако, любой пакет программ не может обеспечить полную универсальность своей системы, но это собственно не к чему. Любое программное обеспечение, благодаря своей специфичности в той или иной области автоматизации проектирования, позволяет получить максимальную эффективность конкретно в своей области. Но, последнее время наметилась тенденция к интеграции программного обеспечения на базе так называемых автоматически связываемых объектов. Этот термин на самом деле означает не интеграцию программ в прямом смысле, а лишь ее эмуляцию. Тем не менее, для конечного пользователя это выглядит как полная интеграция программного обеспечения различных направлений и различных фирм разработчиков программного обеспечения. Идея заключается в том, что любое приложение для Windows, обеспечивающее OLE Automation (Objekt Linking and Embedding Automation - автоматическое связывание и внедрение объектов), может управляться извне другими приложениями, которые пользуются им основываясь на предоставленных приложением программных интерфейсах и таким образом выполнять те же функции, что и приложение прародитель функций.

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

1. АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ

1.1. Выбор и обоснование операционной системы

1.1.1. Графические операционные системы

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

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

Пользователь работает с приложением, находящимся самом “верхнем” окне, но простым щелчком мыши на другом окне он мо­жет активизировать другую программу. Кроме того, уже в своих ран­них версиях Windows позволяла копировать ин­формацию из окна од­ной программы в окно другой программы при помощи средства clip­board - буфера обмена.

Графический режим Windows, как и графический режим лю­бой другой графической операционной среды (Windows NТ,ОS/2, Soleras, Motif ) имеет мало общего с знакоместным графическим режимом, доступным во многих программах для МS-DОS, всегда размещающих на экране стандартное количество символов, напри­мер 8Оx25 или 80x43. Windows (а следовательно, и любая Windows -программа) по­зиционирует графические объекты с точностью до пикселя.

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

Графическая подсистема Windows использует универсальные методы обращения к любым графическим устройствам вывода, будь то видеосистема ЕGА или super VGA, лазерный принтер или автомат для вывода типографских форм. Стандартизован интерфейс Windows, конечно, не с самими дисплеем и принтером, а с драйве­рами этих уст­ройств, причем драйверов в комплект поставки сис­темы Windows входит великое множество.

Выпуск графической операционной оболочки Microsoft Win­dows 3.0 стал главным событием 1990 года на программном рынке, за­тмившим одновременное появление IBM OS/2 1.3. Кроме прият­ного пользовательского интерфейса среда Windows предоставляла значи­тельный комплекс услуг.

С системой поставлялось большое количество драйверов для самых разных моделей устройств ввода-вывода, таких как видео­адап­теры и принтеры. Широчайшая аппаратная совместимость была од­ним из факторов успеха Windows. Комплект Windows 3.0 со­дер­жал несколько вариантов драйверов для разных моделей кла­виатур, мышей и видеоадаптеров и большое количество драйверов принте­ров. В Multimedia для Windows 3.0, а затем в Windows 3.1 появились драйверы звуковых карт, МIDI устройств и синтезато­ров. Количе­ство наименований поддерживаемых устройств быстро росло...

1.1.2. Windows 3.Х

С точки зрения массового пользователя, не избалованного OS/2, Windows 3.0 была действительно передовой средой. Она ис­пользовала весь объем памяти, адресуемой микропроцессорами 80286, 80386 и выше. С 32-разрядными микропроцессорами (80386 и выше) и при наличии не менее 2 Мбайт памяти Windows 3.0 могла использовать виртуальную память, то есть работать с некото­рым пространством на жестком диске как с продолжением опера­тивной памяти компьютера, размещая в нем данные и код про­грамм.

Windows имела многозадачные возможности с кооператив­ным использованием процессорного времени “одновременно” работающими приложениями. Кооперативную

многозадачность можно назвать многозадачностью “второй сту­пени” поскольку она использует более передовые методы, чем .простое переключение задач, реализованное многими извест­ными программами (например, МS-DOS shell из МS-DOS 5.0 при про­стом переключении активная программа получает все процессор­ное время, а фоновые приложения полностью замо­раживаются. При кооперативной многозадачности приложение может захва­тить фактически столько процессорного времени, сколько оно считает нужным. Все приложения делят процес­сорное время, периодически опрашивая друг друга.

С другой стороны, режим кооперативной многозадачности менее совершенен, чем режим разделения времени, называемый также вытесняющей многозадачностью. При вытесняющей много­задачности программы потребляют ровно столько процессорного времени, сколько им положено, а не сколько заблагорассудится. За выделение процессорного времени тому или иному приложе­нию отвечает только операционная система, руководствуясь теку­щими приоритетами. Благодаря этому при вытесняющей многоза­дачности можно в любой момент переключиться на любой процесс, в отличие от кооперативной многозадачности, при которой для пе­реключения между программами может потребоваться существен­ная пауза. При вытесняющей многозадачности кажется, что про­цессы действительно работают одновременно, хотя это на самом деле и не так, - во всяком случае, на компьютере с одним микро­процессором, каким является обычный IВМ РС.

С апреля 1992 года Windows 3.1 официально именуется опе­ра­ционной системой. Интерфейс ее был несколько улучшен, в част­ности были усилены возможности управления экранными объек­тами мышью (Drag - and - drop метод перетаскивания). Windows стала непосредст­венно поддерживать динамический обмен данными между приложе­ниями (DDЕ - Dynamic Data Exchange ). В систему вошли средства мультимедиа, ранее поставлявшиеся отдельно в па­кете Windows Multimedia Extension. Для расширения издательских возможностей в Windows была встроена поддержка системы мас­штабирования шриф­тов TrueType.

Windows 3.11 for Workgroups (“для рабочих групп”) пози­цио­нировалась как самостоятельная сетевая операционная система для одно-ранговой локальной сети, а также как сетевой клиент для сервера Windows NТ. В остальном Windows 3.11 для рабочих групп являлась слегка улучшенной модификацией Windows 3.1, работаю­щей только в 386-м Расширенном режиме на 32-разрядных микропроцессорах.

А теперь мы постараемся разобраться в том, как устроена Win­dows.

Режимы работы Windows 3.X Чтобы запустить мотор Windows на полную мощность, ко­нечно, нужны прежде всего мегабайты и мегабайты оперативной памяти. Но их невозможно использовать на микропроцессорах 8088/86. Не слиш­ком удачным решением был и защищенный режим 80286: для того чтобы использовать на компьютере приложения для новой операци­онной среды вместе с МS-DOS приложениями, при­ходилось переклю­чать микропроцессор из защищенного режима в реальный и обратно.

Здесь уместно вспомнить о том, что фирма Microsoft весьма тесно сотрудничала с Intel во время разработки микропроцессора i80386. Microsoft фактически навязала инженерам Intel собственную концепцию режима виртуального микропроцессора 8086-V86, наи­бо­лее удобную для разработки операционной системы, использую­щей МS-DOS приложения вместе с программами защищенного ре­жима. Поскольку в 1990 году рынок еще не был готов к полному переходу на операционную систему для микропроцессора 80386, Windows 3.О могла функционировать в трех режимах, в каждом из которых микро­процессор и память использовались по-разному.

В реальном режиме работы Windows система функциониро­вать даже на компьютере с микропроцессором 8088 или 8086, обо­рудо­ванном только обычной памятью для работы приложений в ре­альном режиме Windows 3.0 использовалась только обычная па­мять МS-DOS и отображаемая память.

Стандартный режим Windows 3.0 требовал для работы микро­процессор 80286 и всего 1 Мбайт памяти - 640 Кбайт стандартной и 384 Кбайт дополнительной (настоящая работа начиналась при объ­еме памяти 4 Мбайт). Для приложений Windows использовалась расши­ренная память (ХМS). Для программ МS-DOS, загружаемых из-под Windows, применялась обычная память и переключение микропроцес­сора из защищенного режима в реальный.

Более полно использовал аппаратные ресурсы 386-й Расши­рен­ный режим Windows . В этом режиме версии Windows 3.0 и 3.1 рабо­тали с виртуальной памятью, имевший примерно втрое боль­ший объем, чем физическая оперативная память. Приложениям МS DOS в 386-м Расширенном режиме отводилась произвольная об­ласть памяти, которая в виртуальном режиме 8086 размечалась как обычная память MS DOS . По умолчанию МS-DOS программы за­гружались занимая, как обычно, весь экран, но могли быть переве­дены в графическое окно - стандартное окно Windows. Приложения МS-DOS, запущенное из-под Windows в 386-м Расширенном ре­жиме, работало в виртуаль­ной машине, иными словами, считало себя загруженным на своем соб­ственном компьютере и знать не знало о существовании Windows.

Разумеется, для работы в 386-м Расширенном режиме требо­вался компьютер с микропроцессором не ниже 80386. Объявленные требования к объему памяти (2 Мбайт) опять-таки не стоило при­ни­мать всерьез. Минимумом являлись 4 Мбайт памяти, а для бо­лее или менее серьезной работы требовались 8 Mбайт или больше.

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

Ядро Windows состоит из трех компонентов Kernel ,User и GDI. При помощи дополнительных DLL-файлов (динамически за­гру­жаемых библиотек) поддерживаются отображением стандарт­ных диалоговых окон, протоколы DDЕ (динамического связывания дан­ных) и ОLЕ (связывания и встраивания объектов), взаимодейст­вие с драйверами устройств ввода-вывода и другие черты Windows. Win­dows -драйверы устройств бывают, кстати, двух видов - “обычные” DLL-драйверы и 386драйверы, последние предназна­чены опять-таки для работы только в 386-м Расширенном режиме Windows.

Наиболее низкоуровневой частью ядра Windows является мо­дуль Kernel, управляющий распределением памяти, процессами, фай­ловым вводом-выводом и так далее. В разных режимах работы Win­dows 3.О функции Kernel выполняли различные файлы: ker­nel.ЕХЕ для Реального режима krnl286.Еxe для Стандартного ре­жима, КrnlЗ86.ЕХЕ для 38б-го Расширенного режима.

Так что Windows 3.0 была разработана как операционная система, имеющая три разных ядра. Когда был упразднен Реальный режим работы, из комплекта поставки Windows 3.1 и исчез файл Kernel.dll. Следующий шаг был сделан, Windows 3.11 для рабочих групп - эта система работала только в 386-м Расширенном режиме. Модуль User (user.ЕХЕ) служит для работы с клавиатурой, мышью, таймером и портами, а также выполняет функции отображения эле­ментов графического интерфейса (окон, меню). Он управляет та­кими драйверами, как, например, различные драйверы клавиатуры и мыши.

Наконец, модуль GDI (интерфейс графических устройств, файл GDI.ЕХЕ) поддерживает графические процедуры - прорисовку линий, закрашивание, отображение шрифтов (начиная с Windows 3.1 - все операции со шрифтами TrueType) и взаимодействует с драйве­рами графических устройств - дисплея и принтера. С Windows 3.1 поставля­лось более десятка драйверов видеоадаптеров. Для под­держки прин­теров в Windows 3.1 впервые была применена архитек­тура мини-драй­веров. Универсальный драйвер принтера NIDRV.DLL выполнял ап­паратно-независимые функции печати -несколько десятков мини-драйверов, поставляемых производите­лями, дополняли универсаль­ный драйвер функциями обходи­мыми специально для поддержки конкретных устройств и не по­вторяли уже написанный общий код.

1.1.3. Windows 95

В 1996 году фирмой Microsoft , была выпушена следующая версия операционной системы Windows. Которая была названа фирмой 32 разрядной многозадачной графической системой. / 1 /

Архитектура Windows 95.Что должна была сделать Microsoft, чтобы прийти к 32-раз­ряд­ной операционной системе с обеспечением вытесняющей мно­гоза­дачности, которая бы при этом оставалась полностью совмес­тима с прикладными программами для Windows 3.x и MS-DOS, не требо­вала бы для работы самой МS DOS и “умещалась” в четырех мега­байтах оперативной памяти ?

Фирмой Microsoft уже выпущены системы, удовлетворяю­щие самым серьезным требованиям к управлению памятью и про­цес­сами, - Windows NТ SERVER и Windows NТ workstation (выпущены версии 3.51 и готовятся к выпуску 3.52), Однако эти системы сами предъявляют серьезнейшие требования к аппаратуре, а заодно и к пользователю. Windows NТ SERVER предназначается не для десят­ков миллионов потребителей Windows, а для сетевого администри­рования. Windows NТ workstation нужна тем пользова­телям, которые используют приложения с высокой интенсивно­стью вычислитель­ной обработки, тем, кто нуждается в высокой степени безопасности данных, и тем, кто больше беспокоится о надежности системы, чем о совместимости с приложениями для MS DOS и Windows 3.x.

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

Ядро Windows 95. Ядро Windows 95, как и во всех предыдущих версиях Win­dows, имеет трехуровневую структуру Kernel -User- GDI. Все эти модули должны бы быть 32-разрядными, но в действительности полностью 32-разрядной сделана только самая низкоуровневая часть ядра Windows 95 - Кегне1. Вполне понятно, что, объявляя о 32-разрядной сис­теме, Microsoft обязана была выполнить в 32-раз­рядном коде хотя бы такие базовые вещи, как функции ввода- вы­вода, управления памятью и процессами, поддержку сетевой и фай­ловой систем.

Что касается двух других модулей ядра, то расчеты показали, что полностью 32-разрядные USER и GDI вместе потребуют для ра­боты более 1 Мбайт памяти, Windows 95 использует 1б-разрядный код, когда он необходим для обеспечения совместимости или если 32-разрядное кодирование нецелесообразно, то есть увеличило бы расход памяти без заметного увеличения производительности.

Поэтому модуль User, остался в Windows 95 преимущест­венно 1б-разрядным, а его 32-разрядная часть используется для пе­реадреса­ции вызовов 32-разрядных приложений 16-разрядному блоку. Боль­шая часть функций ОВ1, включая подсистему буфериза­ции входных и выходных потоков, подсистему печати, растеризатор шрифтов True­Туре и основные операции рисования, перенесена в 32-разрядный мо­дуль, оставшийся 16-разрядный код описывает управление окнами. 16-разрядные функции ядра Windows 95 напи­саны преимущественно на ассемблере .Что же касается Kernel, то его 16-разрядная часть задей­ствуется только при загрузке Windows 95 и используется только для инициализации 32-разрядной части Kernel. Сам Kernel32 никогда не обращается к Kernel16. На рис.1.2. показано, для каких функций ис­пользуется 32-разрядный код, а для каких 16-разрядный код модулей ядра Windows 95.

Многозадачность. Анализируя выполнение под Windows 95 16-разрядных приложений для Windows 3.x и МS-DOS, мы видим по большей части знакомые, хотя и серьезно улучшенные методы Win­dows 3.x.

Как показано на рис. 1.3., 16-разрядные приложения для Windows (“приложения win16”) выполняются в общем простран­стве адресов в пределах системной виртуальной машины. Такие ва­рианты, как выполнение каждого приложения win16 в отдель­ной виртуальной машине (что возможно в ОS/2) или полная эмуляция Windows 3.x в пределах операционной системы (как это делается в Windows NТ).

32-разрядные приложения, созданные с учетом требова­ний Windows 95 (“приложения win32”), выполняются в режиме “подлинной” вытесняющей многозадачности. Кроме того, Win­dows 95 поддерживает многопоточные приложения, способ­ные за­пускать параллельно несколько процессов.

Для каждого win32-приложения и для области адресов приложений win1б используются отдельные очереди сообще­ний. Таким образом, приложения win16 фактически изолиро­ваны от остальных процессов. Кроме того, в Windows 95 приме­ненные ме­тоды очистки и восстановления системы в случае оши­бок. Если ошибка в программе, выполняющейся под Windows 3.x, могла за­просто “обрушить всю” систему, то ошибка в одном из приложений под Windows 95 обычно не влияет на выполнение остальных про­грамм. Низкоуровневые компоненты операционной системы изоли­рованы от прикладных программ, поскольку пользуются сервисом другого уровня защиты микропроцессора 80386.

Использование памяти. Для разработчиков программного обеспечения 1ВМ РС дол­гие годы оставалась камнем преткновения сегментированная мо­дель па­мяти 1б-разрядных микропроцессоров 8088/86 и 80286.

Сегментом является непрерывная область памяти, адресуемая 16-разрядными числами ( 64 Кбайт ). Для того чтобы использовать бо­лее б4 Кбайт памяти, пришлось разработать систему адресации памяти при помощи двух чисел - адреса начала сегмента и 1б-раз­рядного смещения внутри сегмента. Микропроцессоры 80386, спо­собные опе­рировать 32-разрядными адресами, могли бы без всяких премудростей ( и отнимающих время вычислений! ) адресовать до 4 Гбайт, оператив­ной памяти, Но МS-DOS и Windows 3.x вынужденно продолжали ис­пользовать устаревшую сегментированную модель памяти.

Для win32-приложений доступна плоская ( несегментированная) модель памяти Windows 95. Система пол­но­стью использует адресуемую память 38б-х процессоров, при этом прикладные программы могут работать с объемом па­мяти до 2 Гбайт, остальные 2 Гбайт Windows 95 использует для собственных нужд. Файл виртуальной памяти Windows 95 имеет динамический размер, ограниченный только объемом жест­кого диска и не зави­сящий от фрагментации.

Использование системных ресурсов. Под системными ресурсами в терминологии Windows пони­мают области памяти, используемые модулями USER и GDI. В ресурсах GDI располагается информация о графических объек­тах, исполь­зуемых системой в данный момент. Ресурсы USER включают ин­формацию об окнах, меню и так далее. Для того чтобы максимально ускорить процедуру обращения к ресурсам USER и GDI, в Windows 3.x их объемы ограничили сегментами по б4 Кбайт. Каждое поро­жденное системой окно отнимало при­мерно 2% системных ресурсов, а когда процент свободных сис­темных ресурсов падал до 20%, за­грузка новых приложений стано­вилась невозможной.

Большая часть ресурсов Windows 95 хранится в областях па­мяти с 32-разрядной адресацией, Соответственно объем ресур­сов Win­dows 95 практически неограничен. Те из старых Windows -про­грамм, ко­торые непосредственно обращаются к системным ресур­сам, могут использовать их под Windows 95 так же, как и прежде.

Файловая система. Одно из самых назойливых ограничений систем МS-DOS и Windows 3.x - имена файлов, состоящие не более чем из 11 (8+3) символов. Новая файловая система позволяет win32-приложениям пользоваться длинными (до 255 символов) именами файлов и при этом остается полностью совместимой с FAT. Разумеется, пользо­ваться такими именами файлов гораздо удобнее.

Некоторые компоненты новой файловой системы были ис­пользованы еще в Windows 3.11 для рабочих групп - драйвер ус­та­навливаемых файловых систем, 32-разрядный драйвер FАТ, 32-раз­рядное кэширование жесткого диска. Все эти черты получили даль­нейшее развитие в Windows 95. Кроме того, появились 32-раз­рядный драйвер CD-ROM, более мощная подсистема блокового ввода-вы­вода и другие черты.

Поддержка драйверов устройств. аиболее громоздкие МS-DOS драйверы, занимавшие больше всего места в базовой памяти или UMB, теперь не нужны при ис­пользовании оболочки защищенного режима. Согласно докумен­тации Microsoft система Windows 95 обеспечивает:

• полную поддержку разделения доступа к файлам, заменяя рези­дентную программу SНАRЕ.ЕХЕ;

• полную поддержку разнообразных звуковых плат, СD-ROM при­водов и других мультимедиа-устройств, не требуя при этом уста­новки МS-DOS драйверов;

• поддержку файловой системы СD-RОМ дисков, заменяя MSCDЕХ.ЕХЕ;

• кэширование дисков, заменяя SMARTDrive;

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

• динамическое сжатие данных, заменяя DRVSpace.BIN (DBLSPACE.BIN);

• полную поддержку работы станции в локальных сетях MS-NЕТ и Novell Netware, заменяя все резидентные программы, ко­торые приходилось загружать для работы в этих сетях.

Windows 95 поддерживает текущую версию протокола Plug-and-Play. При установке дополнительного устройства, подключае­мого на основе Plug-and-Play, система сама заботится о его конфи­гурировании.

Достаточно удобно использовать Windows 95 и без аппаратной под­держки Plug-and-Play - система чрезвычайно много знает о том, ка­кие существуют внешние устройства и как идентифицировать, включая СD дисководы, звуковые карты модемы, мыши и многое другое.

Графическая оболочка Windows 95. Интерфейс Windows 95 соответствует требованиям самых придирчи­вых пользователей, дизайнеров и специалистов по эрго­номике. На мой взгляд, интерфейс Windows 95 великолепен, и пе­рейти на эту систему стоило бы даже в том случае, если бы новым в ней был только интер­фейс.

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

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

Широкие возможности настройки. Windows 95 можно настроить сотнями способов, причем доступ к средствам настройки пользова­ние ими весьма просты.

Удобство работы с документами. Windows 95 - это следующий шаг к интеграции различных прикладных программ одну рабочую среду. Можно легко создавать документы средствами оболочки, переносить данные из документа на рабочий стол и в другой доку­мент, выбрасывать в “мусорную корзину” фраг­менты текста, доку­менты или целые папки, а при необходимости - возвращать их.

Усовершенствованная справочная система. Справочная система Windows стала удобнее и гибче. Многие разделы справки состав­лены в виде пошаговых руководств с возможностью выполнения тех или иных рекомендуемых действий непосредственно из системы помощи.

“Эмуляция” MS-DOS.MS-DOS 7.0 + Windows 4.0.Покинуть оболочку Windows 95 для работы с МS-DOS про­граммами в реальном режиме можно, только инициировав пере­загрузку или отключение системы или же перейдя в режим эму­ляции МS-DОS (МS-DOS mode) с возможностью возврата в графическую оболочку по команде ЕХIТ. Похоже, что нормаль­ным состоянием Windows 95 действительно является графический интерфейс, который всегда на­ходится где-то под рукой, в памяти компьютера. Но это не так.

В действительности “режим эмуляции МS-DOS” представляет собой классическую МS-DOS, работающую в реальном режиме и адре­сующую 640 Кбайт оперативной памяти. Графическая система Win­dows 95 со всеми своими преимуществами по-прежнему явля­ется оболочкой защищенного режима для MS-DOS. Даже новейшие 32-разрядные графические приложения для Windows 95 продол­жают ис­пользовать для выполнения отдельных операций функции МS-DOS и базовую область памяти.

Таким образом, определение Microsoft Windows 95 как опера­ционной системы, не требующей отдельной копии МS-DOS, осно­вано на том, что Windows 95 включает в себя все, что ей нужно от МS-DOS. Ничто лучше МS-DOS не поддержит MS-DOS-приложе­ния, именно в МS-DOS лучше всего чувствуют себя те 16-разрядные драйверы уст­ройств, которые все-таки приходится загружать (например, драйверы сканеров).

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

1.2. Анализ механизма связывания и внедрения

Научно-технический прогресс 90-х годов обусловил неук­лонный рост популярности объектно-ориентированного програм­мирова­ния (ООП), и в настоящее время многие программисты перешли в своей работе на С++ или Visual Basic. Уже существуют объектно-ориентированные базы данных, объектно-ориентирован­ные дизайн и анализ и даже объектно-ориентированный СОВОL. На естественно воз­никающий вопрос - не остались ли Windows или операционные системы в объ­ектно-ориентированном отноше­нии далеко позади. Безус­ловно, нет. Продукт OLE ( Objekt Linking and Embedding ) компании Microsoft откры­вает новые пути для при­менения объектов в Windows. ОLE предполагает новый способ мышления. Про­граммист в среде ОПП должен мыслить обо всем как об объектах - от файла на диске, эле­мента данных или прило­жения до аппаратного обеспечения и операционной сис­темы. Кроме того, OLE заставляет программиста следовать строгому на­бору правил, на за­висящих от языка программирования, операци­онной системы или даже от аппарат­ной платформы.

Введение в OLE. OLE служит основанием, на котором строятся объекты. Эта аббре­виатура означала изначально связывание и внедрение объек­тов (Objekt Linking and Embedding) с выпуском версии ОLE 2 приме­нение ОLE уже не укладыва­ется в рамках, связывания и внедрения. ОLЕ сегодня включает в себя унифициро­ванную передачу данных, структурированное хранилище информации и автоматиза­цию. Не следует сужать представление об ОLЕ связыванием и внедрением; смотреть на ОLЕ следует как на набор строительных блоков, позво­ляющих создавать сложные приложения. На самом деле Microsoft перестала расшифровывать аббревиатуру ОLE как Objekt Linking and Embedding, чтобы изменить сложившееся восприятие ОLЕ.) / 2 /

Предназначение и история ОLЕ. Если до появления OLE 1 у пользователя Windows имелась элек­тронная таблица, которую ему нужно было вставить в документ текстового редактора, обыкновенно он должен был экспортировать данные из таблицы в файл стандартного формата, импортировать данные из файла в текстовый редактор, а затем в редакторе их пере­форматировать. Если пользователю везло и оба приложения под­держивали копирование и вставку, то вместо явного экс­порта/импорта он мог копировать информацию через буфер Clip­board. Всякий раз, когда электронные таблицы изменялись, процесс переноса данных нужно было повторять. Это, естественно, приво­дило к лишней затрате времени и сил.

Но незадолго до выхода Windows 3.1 появилось ОLE 1, и это значи­тельно упростило описанную использования общих данных в по­добных приложениях (если они умели работать с ОLЕ). На смену операциям экс­порта/импорта и копирования пришли связывание и внедрение. Стало возможным так подключить электронную таблицу к текстовому редактору, чтобы документ редактора отражал самые последние изменения, произошедшие в электронной таблице. Кроме того, электронная таблица (которая появилась в текстовом доку­менте) может быть выбрана нажатием кнопки мыши. При этом ав­томатически запускается приложение электронной таблицы, позво­ляющее выполнять редактирование данных или другие специфиче­ские для таблиц операции. Команда Update закрывает электронную таблицу, и обновленная электронная таблица внедряется в документ текстового процессора.

OLE 2 является следующим логическим шагом в развитии этой стра­тегии. В ОLE 1 нажатие кнопки на электронной таблице, находящейся в документе текстового документа, приводило к за­пуску приложения в отдельном окне. В ОLЕ 2 вводится понятие ак­тивации по месту (также известное под названием визуального ре­дактирования). Приложение электронной таблицы запускается как и прежде, но вместо отдельного окна электронная таблица как бы сливается с тек­стовым редактором. Изменяется меню, отражая меню электронной таблицы. Из­меняется даже инструментальные линейки, но вы все равно находитесь в текстовом редакторе. Два приложения как бы соединяются и текстовый редактор приобретает функциональные возможности электронной таблицы. Так пользова­телю нужды переключаться для просмотра данных с одного прило­жения на другое; вы можете ра­ботать с приложением, которое удовлетворяет большинству ваших потребностей, и внутри него использовать возможности других приложений.

Для ОLE 2 пришлось переделать заново многое из существо­вавшего в ОLE 1 чтобы расширить его функции и улучшить произ­водительность. Напри­мер, ОLЕ 1 построено на динамическом об­мене данными (DDЕ). Для передачи информа­ции туда и обратно DDE в своей основе использует сообщения Windows и возврат­ные вызовы. Поскольку используются сообщения Windows, DDЕ огра­ничивается рам­ками одной машины. OLE2 не опирается на DDE вместо этого оно построено на протоколе LPRC (Lightweight Remote Procedure Calls - легких удаленных процедурных вы­зовах).

Архитектура ОLЕ. Чтобы достигнуть своих задуманных функциональных воз­можностей, ОLE в качестве строительных блоков использует боль­шое количество объектов. OLE содержит новые объекты для реали­зации таких концепций, как формировка (marshaling), которая об­служивает коммуникацию между процес­сами и опирается на LPRC; структурированное хранилище, которое обес­печивает хранение до­кументов, содержащих другие документы; ярлык (moniker), управ­ляющий подключением и переключением связанных данных. Каж­дый из этих механизмов необходим ОLE для выполнения своей ра­боты. Кроме того, ОLE вводит понятие автоматизации, которое не требуется для связывания и внедрения в традиционном смысле. Ав­томатизацию можно понимать как способ, посредст­вом которого пользователь может работать с вашим приложением внутри опреде­ленного им самим макроязыка. Сервер-автомат OLЕ управляется любым автомат­ным контроллером OLE (см. таблицу).

Приложения-автоматы - серверы и контроллеры.

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

Объекты. Под понятие о6ьекта ОLЕ попадает все, что может иметь ма­шинное представление. Объектом может быть документ текстового процессора, рисунок или чертеж, также часть чертежа (допустим какой либо слой чертежа печатной платы), видео-клип, звук или даже приложение. Та­кое понимание расходится со стандартной ин­терпретацией, в которой объекты - дан­ные, над которыми произво­дятся манипуляции посредством функций и процедур. Хотя OLE поддерживает объекты только в рамках одной машины, это не огра­ничение архитектуры OLE, а лишь ограниченность ее реализации. Уже демонст­рировалась версия OLE, названная распределенным ОLЕ, в которой границы ме­жду машинами для объектов про­зрачны. Другими словами, если ваше приложение запра­шивает OLE-объект, то поставщик этого объекта не обязательно находится на вашей машине, хотя с точки зрения вашего приложения ОLE -объ­ект - локальный.

Интерфейсы. OLЕ интерфейс - это механизм, используемый для доступа к группе связанных с объектом функций. Если вы хотите выполнить в OLE операцию над объектом, можно запросить специфический ин­терфейс, имеющий нужную вам функцию. Когда вы запрашиваете интерфейс, то обращаетесь к объекту, указывая его ID-номер. Каж­дый интерфейс имеет уникальный номер-идентификатор (Interface ID или IID). Объект возвращает либо состояние ошибки, если объект не поддерживает запрашиваемый интерфейс или происходит другая ошибка, либо он возвращает указа­тель на требуемый интерфейс.

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

Структурированное хранилище. Структурированное хранилище - это спецификация, опреде­ляющая метод хранения объектов. Структурированное хранилище можно представить себе как OLE-аналог DOS. Этот механизм под­держивает большинство из функций DOS - файлы и каталоги, ко­пирование и перемещение файлов (файлы называются потоками, а ката­логи - хранилищами. Кроме того, термин “структурированное хранилище” информации не подразумевает, что данные хранятся на диске. Так же как и файлы DOS, которые могут находится на RAM-диске, жестком диске, флоппи-диске или даже на CD-ROM, объ­екты, размещенные в структурированном хранилище, могут нахо­диться в любом из этих мест, а также и в других. Чтобы DOS могла использовать для хранения информации другие устройства, такие, как оптический флоппи-диск или се­тевой диск, обычно нужен драй­вер устройства. Структурированное хранилище инфор­мации также имеет методы для поддержки нестандартных устройств.

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

Автоматизация. OLE-автоматизация - это надзор интерфейсов, в типичном слу­чае псзволяющий использовать приложение в качестве ОLЕ объ­екта. Автоматизация возможна не только для приложений в форме исполняемых модулей (ЕХЕ), но и для динамически присоединяе­мых библиотек (DLL). Автоматизация позволяет посредст­вом на­бора определенных правил извне запрограммировать или специали­зировать приложение. Это дает приложению, например, Visual Basic, возможность управлять Exel, в результате чего функции Ехсеl ста­новятся доступны вашему приложению на Visual Basic. Автоматный контроллер OLE управляет объектами-автоматами через посредство автоматного сервера.

Унифицированная передача данных. Унифицированная передача данных - это набор интерфейсов, которые позволяют клиенту и серверу обмениваться данными. Она является DDE-эквивалентом и функций буфера cut/сору/paste, соб­ранных воедино. Унифици­рованная передача данных посылает уве­домление в случай если данные изменяются (подобно связи DDE), а также поддерживает переговоры о формате, в котором данные бу­дут передаваться. Кроме того, унифицированная передача данных предусматри­вает возможность передачи одного лишь дескриптора (handle) данных вместо самих данных. Объект-сервер может ре­шить, что вместо передачи 20 Мбайт данных в оперативную память через буфер обмена объекту-клиенту будет передан дескриптор дан­ных, чтобы клиент сам мог их получить. Это избавляет сервер от необходимости чтения всех данных и передачи их клиенту, а кли­ента от необходимости самостоятельной обработки данных. Это также избавляет конечного пользователя от сидения перед экраном компьютера в ожидании окончания обмена.

Связывание и внедрение (Linking and Embedding). Связывание и внедрение - два принципа, которые по тради­ции известны в OLE (Objekt Linking and Embedding) лучше всего. Связы­вание и внедрение (вместо этого теперь говорят просто о докумен­тах ОLЕ) позволяют объекту-клиенту (который может быть другим приложением) прикрепиться к объекту-серверу. Присоединение может либо осуществляться связыванием (данные находятся вне со­ставного документа), либо данные могут внедряться внутрь со­ставного документа. Вне­дренные данные сохраняются непосредст­венно в документе, в то время как при связыва­нии для доступа к данным OLE в действительности сохраняет своего рода до­рожную карту. Дорожной карта называется ярлыком (moniker). Когда ОLЕ получает за­прос на восстановления данных, оно смотрит на ярлык (дорожную карту), чтобы их отыскать. Связанные данные могут храниться в не принадлежащем ОLЕ файле или в структурирован­ном хранилище (возможно даже, что данные находятся где-то в са­мом составном документе).

Составной частью связывания и внедрения является способ­ность OLE выполнять активацию по месту. В OLE 1 при двойном нажатии кнопки мыши над связанным или внедренным объектом запускается сервер этого объекта. В ОLЕ 2 возможна активация по месту. Для пользователя два приложения являются как бы одним. Активация по месту присое­диняет нужные части приложения сер­вера (такие, как пункты меню и инструмен­тальные линейки) к при­ложению клиента, когда пользователь работает с внедренным объ­ектом. При двойном нажатии кнопкой мыши над внедренным объ­ектом происходит преобразование приложения клиента, в нем изме­няются меню и линейки инструментов, а также прочие элементы интерфейса, для работы с приложением сервера внедренного объ­екта. При двойном нажатии кнопкой мыши над связанным объектом приложение сервер запускается в отдельном окне (как в OLE 1).

В терминах OLE описанное выше действие (двойное нажатие для ак­тивации сервера) называется активацией извне (outside-in). При акти­вации извне сервер объекта не активируется (не за­пуска­ется), пока пользователь не нажмет над объектом кнопку мыши дважды. Активация изнутри (inside-out) требует, чтобы объект-кли­ент активи­ровал объект-сервер всегда, когда объект-сервер виден. Сервер принимает управление по однократному нажатию кнопки мыши - потому, что для активируемых изнутри объек­тов он уже за­пущен заранее.

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

1.3. Выбор и обоснование языка программирования

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

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

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

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

4. Использование уже существующего кода, возможно, напи­санного на другом языке программирования.

При разработке приложений для Windows вышеизложенным принципам очень удачно соответствует Visual Basic. Основные свойства этого языка программирования приведены ниже.

Возможности Visual Basic.

1. Все элементы пользовательского интерфейса можно созда­вать/модернизировать/удалять без всякой связи с алгоритмической "невидимой" частью программы. Все, что связано с взаимодейст­вием с человеком или другим субъектом управления, находится в файлах форм (FRМ), VВХ и ОСХ, а все, что связано с расчетной частью, - в файлах стандартных модулей (ВАS) и классов(СLS), или, если нужна скорость обработки - в специально написанных на С, Pascal, Fortran или других язык программирования, DLL. Но это разнесение на самом деле чисто условно и делается просто с це­лью облегчения работы самому разработчику или, что более важно, - группе разработчиков. На самом деле, при небрежном проектировании или небольшой поставленной задаче и интерфейс­ная и алгоритмическая часть могут располагаться в одном модуле (FRМ или ВАS).

2. Формирование пользовательского интерфейса в Visual Basic похоже на работу с детским конструктором - все элементы на виду, все элементы просты, но сложность создаваемой конструкции ог­раничена только изобретательностью разработчика. Причем надо иметь ввиду, что число элементов этого конструктора постоянно и очень быстро растет. Сотни (на начало 1995 года около тысячи) сторонних производителей и фирм постоянно выбрасывают на ры­нок все новые, более мощные модели расширения для Visual Basic.

3. Если уже имеется готовый алгоритм БПФ (Быстрого Преобра­зования Фурье) на ассемблере или алгоритм быстрого поиска в от­сортированном списке на С или Pascal, не надо переписывать их на Visual Basic. Достаточно оформить их виде DLL и использовать как функции.

4. Можно с помощью Visual Basic для Windows создавать запус­каемые “.EXЕ” файлы. Visual Basic для Windows создает выполняе­мые (“. ЕХЕ”) файлы, но не самодостаточные. Все программы, созданные на Visual Basic, должны распространяться с файлом VBRUNx00.DLL (x - номер версии 1,2 или 3) или VB400xx.DLL (xx - 16 или 32). Эта DLL обязательно должна присутствовать в каждой системе, где используются программы на Visual Basic для Windows.

Visual Basic дает возможность создавать приложения, рабо­тающие среде Windows. Программы компилируются в псевдокод (р-коде) и помещаются в файлы с расширением “.ЕХЕ”. Когда программа запускается, файл с р-соdе обращается к VBxxxx.DLL, которая интерпретирует р-code в последовательность инструкций Windows АРI.

5. Использование функций Windows АРI в Visual Basic до­вольно просто - необходимо ее объявить (declare) в секции объяв­лений или модуле кода.

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

6. Используемый механизм добавления элементов управления VВХ ( Visual Basic eXtension - модули расширения Visual Basic) явил собой "черный ход" для разработчиков третьих фирм по внедрению собственных объектов в среду разработки Visual Basic. Механизм, пусть и не объектно-ориентированный, но позволяет просто и довольно элегантным путем добавлять новые программ­ные компоненты без дополнительного программирования. Меха­низм VВХ является специфическим интерфейсом для Visual Basic.

7. Существует открытый стандартный интерфейс для работы с программными компонентами, в каждую программу и приложение можно интегрировать стандартный набор средств, позволяющий использовать в дальнейшем данные программы в виде компонент для будущих приложений. Механизм ОLЕ и новая технология в виде ОСХ (ОLЕ Custom Control). ОLЕ не только предлагает стандарт в определении объекта, но также определяет, как и каким образом объекты могут взаимодействовать друг с другом. / 3 /

Основные новшества в Visual Basic версии 4.0

• наличие 16- и 32-разрядной редакции;

• работа в среде Windows 3.1, Windows для Рабочих Групп 3.11, Windows 95, Windows NТ;

• возможность создания ОLЕ Automation объектов;

• поддержка OСХ и VВХ;

• расширение ТооlВох (Окно Инструментария) за счет ОLЕ In­sertable объектов;

• использование JЕТ версии 2.5;

• наличие новых и поддержка специализированных Data Bound Control (объектов, значительно упрощающих работу с базами данных);

• использование ВАО версии 2.0;

• открытая и расширяемая среда разработки;

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

• расширение лексики языка программирования;

• запуск одновременно нескольких копий Visual Basic 4.0;

• директивы условной компиляции;

• поддержка файлов-ресурсов;

• создание 32-разрядных приложений;

Директивы условной компиляции программы. Разработ­чик имеет возможность, используя директивы условной компиля­ции выбирать, например, какую версию приложения (16- или 32-разрядную) он собирается создать. Используя подобные дирек­тивы, можно создавать программы, имеющие один и тот же исходный текст, но которые после компиляции смогут работать на раз­личных платформах.

Object Browser (Инспектор объектов). Данное средство предназначено для облегчения идентификации и управления всеми ОLЕ Automation Servers, на которые есть ссылки в проекте. Выбрав нужный объект, разработчик может легко выбрать и передать кор­ректный синтаксис выражения работы с объектом в текст про­граммы или вызвать встроенную помощь для данного объекта.

Встроенный редактор. Увеличена функциональны мощь встроенного редактора. Во-первых, расширены возможности на­стройки, точнее постройки, “на свой вкус” формата отображаемых строк кода, комментариев, ключевых слов, идентификаторов, точек останова, и т. д. Можно задать различные фонты, цвета и размеры фонтов для облегчения чтения текста программы. Во-вторых, улучшена работа с отладочным окном. Больше нет необходимости держать и окно с отлаживаемым текстом программы и окно с ото­бражаемыми переменными - теперь достаточно использовать одно окно, состоящее из двух подвижных частей: нижнее подокно пред­ставляет собой полнофункциональный редактор кода, верхнее же показывает содержимое переменных.

Расширение лексики языка программирования. Для объ­явления подпрограмм и функций, доступных или не доступных из других модулей проекта, введены дополнительные служебные слова при объявлении процедур: Public и Private соответственно. Visual Basic 4.0 “прихватил” теперь кусочек Pascal, добавив к своему лексическому запасу выражения “With”,”For Each”, а также добав­лены новые типы данных - Byte (простое без знаковое, для пред­ставления чисел в диапазоне 0-255), Вооlean 16 битовые (2-байта) числа, которые могут принимать только два значения: True или False) и Collection. Collection позволяет построить собственную группу пронумерованных объектов. Использование Collection более предпочтительно, чем использование массивов вследствие большей гибкости индексов, и наличия наследуемых методов для вставляе­мых и удаляемых объектов коллекции.

Процедуры свойств (property procedures). Появилась воз­можность создавать для объектов (форм, стандартных модулей и модулей классов) собственные специализированные свойства (properties), и привязывать к ним выполняемый код, который будет вызываться при обращении к свойству.

Расширяемость оболочки программирования. Оболочка разработки (IDE) самого Visual Basic 4.0 также может быть управ­ляем через ОLЕ Automation, что позволяет ОLЕ приложениям созда­вать и размещать в специальное меню Add-In Visual Basic 4.0 свои команды, расширяя таким образом возможности IDE.

Создание ОLЕ Objekt приложений и классы (Сlasses). Од­ной из основных претензий к Visual Basic со стороны профес­сиональных программистов служило отсутствие средств создания готовых модулей для последующего использования. Программист вынужден был обращаться к С, С++, Раsсаl или другим языкам программирования для создания DLL и вызовам функций DLL из программы на Visual Basic или, например, из приложения Microsoft Office. С выходом Visual Basic 4.0 данная ситуация коренным обра­зом изменилась, программисты могут создать объекты ОLЕ Automation. Библиотеки подобных объектов, каждый со своими ха­рактеристиками и методами управления, могут быть использованы из любого приложения, имеющего возможность контролировать приложение, являющееся ОLЕ объектом (OLE Object Application).

По определению, такие объекты названы классами (Claases) - (эту часть языка Visual Basic взял от С++) и располагаются в специ­альных модулях (class module). Для совместимости с программами, реализованными в третьей версии и использующими VВХ из стан­дартного набора, Visual Basic 4.0 включает ОLЕ Custom Control (OCX), заменяющие эти VВХ. При вызове проекта программы, раз­работанной в среде предыдущей версии Visual Basic и использую­щей один из стандартных VBX предложит автоматически преобра­зовать ссылки на новые ОСХ. Такие приложения, как Microsoft Ex­cel для Windows, Microsoft Word для Windows и другие, являющиеся ОLЕ приложениями, теперь можно вставлять в Окно Инструмента­рия (ТооlBох) как обычные элементы управления.

Таким образом можно сказать об некоторой универсальности Visual Basic для создания приложений для Windows.

2. РАЗРАБОТКА СТРУКТУРНОЙ СХЕМЫ И АЛГОРИТМОВ ПРОГРАММЫ

2.1. Функциональная схема работы Windows 95

Операционная система должна обеспечивать взаимодействие приложения как самой верхней ступени с самым нижним уровнем иерархии - аппаратной частью компьютера, через набор каких-либо стандартных функций и подпрограмм. Кроме того она должна обеспечивать пользователя удобным интерфейсом. Рассмотрим как это реализовано в выбранной операционной системе Windows 95. Функциональная схема работы операционной системы Windows 95 представленная на рис 2.1.

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

Windows 95 обеспечивает взаимодействие с внешними устройствами как с потоками информации независимо от самого устройства через свои собственные драйвера устройств.

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

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

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

2.2. Используемая терминология

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

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

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

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

Любая, даже простейшая программа на Visual Basic, имеет свой Проект (project), информацию о котором хранится в специальном файле. В проект программы, отображаемом в специальном окне Проекта, помещаются все формы, модули и файлы, совокупность которых и составляет программу.

Visual Basic не является объектно-ориентированным языком в догматическом понимании ООП (объектно-ориентированное программирование), Visual Basic базируется на парадигме событийно-ориентированного программирования: программа - суть некий набор реального или виртуального мира, каждый из которых понимает некий ограниченный набор событий (возможна, расширяемый). По приходу каждого события из набора отслеживаемых событий формы и элементы управления могут реагировать определенным образом, в соответствии с программным кодом, реализованным программистом для каждого объекта.

Для внесения управляющего программного кода для событий и методов используется Редактор Кода, который служит для создания, просмотра и модификации подпрограмм (Sub) и функций (Function). Процедура представляет собой подпрограмму, которая не возвращает результата.

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

Программный код может находиться в специальных программных модулях (стандартные модули и модули классов) или быть “привязан” только к элементу управления (то есть объекту) или форме.

Кроме набора событий (events), для каждого элемента управления существует предопределенный (возможно, расширяемый) набор свойств или характеристик (properties), представляющих собой некие начальные установки. Данные свойства разделяются по сфере доступности: есть свойства, которые могут устанавливаться только в режиме разработки, только во время выполнения программы или в обоих случаях. Установка и настройка свойств объектов осуществляется в окне Свойств (Properties).

Для элементов управления и форм также существует связанный с ними набор методов (method), которые можно рассматривать как набор команд, понимаемых данным объектом.

Для некоторых отображаемых на экране элементов управления есть возможность задавать различные основные цвета и цвета фона. Для удобства выбора нужных цветов используется Цветовая Палитра (Color Palette).

2.3. Синтез общей структурной схемы программы

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

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

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

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

Дочерними формами по отношению к главной форме являются, форма создания и редактирования свойств документов (MakeDocForm.frm), форма создания и редактирования свойств функций OLE Automation (MakeFunkForm.frm), форма создания и изменения регистрационных данных приложений поддерживающих OLE Automation или для которых необходима эмуляция этой поддержки (MakeDocForm.frm).

Форма создания и редактирования свойств документов содержит все необходимые элементы управления (объекты) для ввода и изменения данных о документе, а также его визуальном представлении в проекте (то есть его иконки).Также в этой форме содержится программный код обрабатывающий эти элементы управления и вносящий изменения в глобальную структуру данных о документах в проекте. Эта форма представляет собой окно под названием “Свойства документа”.

Форма создания и изменения регистрационных данных приложений также представляет собой окно под названием “Регистратор приложений” и также содержит в себе ряд объектов (элементов управления) и программный код обрабатывающий эти элементы управления для изменения данных о зарегистрированных приложениях которые могут участвовать в проекте в качестве непосредственных обработчиках документов, а также в виде функции OLE Automation.

Форма создания и редактирования свойств функций OLE Automation представляет собой окно “Свойства функции” и содержит элементы управления позволяющие редактировать свойства функции OLE Automation. Форма также содержит программный код модифицирующий глобальные данные о функциях в проекте.

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

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

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

2.4. Разработка структурной схемы взаимодействия программы с механизмом связывания и внедрения

Для более качественной разработки алгоритма взаимодействия программы с механизмом связывания и внедрения объектов Windows 95, необходимо рассмотреть функциональную схему работы OLE и системы OLE Automation (рис 2.3).

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

• OLE Server - OLE сервер это приложение обеспечивающее некоторое количество функций

• OLE Client (Controller) - OLE клиент (контроллер) является приложением которое пользуется функциями OLE Automation OLE клиента

• Windows 95/NT является посредником между клиентами и серверами OLE обеспечивая их взаимодействие через ряд стандартных потоков и буферов обмена информацией OLE.

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

Windows 95 являясь посредником во всех операциях между клиентом и сервером, выполняет координирующую роль администратора при передаче данных. А также именно Windows хранит информацию о всех интерфейсах серверов, здесь существует структурированное хранилище для этих целей. Также Windows выполняет регистрацию этих интерфейсов и отвечает на запросы IID от клиентов. Кроме того Windows содержит буфер обмена информацией между клиентом и сервером. Блок OLE Automation производит непосредственное соединение сервера и клиента и обеспечивает их взаимодействие.

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

OLE клиент (контроллер) должен, кроме естественно вызовов самих методов OLE, обеспечивать корректную обработку всех сообщений в обратном направлении (от сервера), Клиент состоит из трех взаимосвязанных частей: блок запроса IID для интерфейса объекта, блок обработки ОLE документа и самого OLE объекта. Первая часть выполняет только подготовительную функцию, она запрашивает IID интерфейс для конкретного объекта у Windows 95, получает этот интерфейс и передает его дальше во второй блок. Во втором блоке проиходит сама обработка документа OLE объекта. Именно в этом блоке обрабатываются такие события как активация извне и активация изнутри. Применяя при этом соответствующие методы обработки этих событий по полученным от первого блока интерфейсы. По этим интерфейсам блок производит активизацию методов применяя либо уже заранее известную информацию о параметрах методов и ответной реакции методов на их активацию, либо полученную через интерфейс эту же информацию. Таким образом воздействуя на объект и являясь посредником при передаче информации между методами сервера и объектом.

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

Таким же образом как и структура OLE клиента, должна выглядеть структурная схема той части контроллера автоматически связываемых объектов, которая отвечающая за взаимодействие с механизмом связывания и внедрения Windows 95.

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

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

Таким образом произведен синтез структурной схемы взаимодействия с механизмом связывания и внедрения (OLE).

1. Разработка структуры данных

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

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

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

Данные о регистрированных приложения состоят из следующих частей:

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

• описание - текст описывающий работу приложения, составляется пользователем;

• имя файла - указатель на запускаемый файл приложения для работы с ним блока OLE Automation;

• имя приложения - собственное расширенное имя приложения указываемое для удобства работы с программой;

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

Данные о документах находящихся в проекте хранятся в следующей структуре:

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

• описание - текст описывающий документ, составляется пользователем;

• имя файла - путь и имя файла документа;

• время создания документа;

• имя приложения - имя приложения которое обрабатывает этот документ (выбирается из зарегистрированных в программе приложений или стандартный обработчик Windows документа с таким расширением) ;

• иконка - путь и имя иконки для визуального представления документа в окне проекта;

• подпись - текст под иконкой документа в окне проекта;

• координаты документа в окне проекта;

• указатели на исходящие из документа функции OLE в проекте.

Наиболее объемными являются данные о функциях OLE содержащихся в проекте, состоящие из следующих переменных:

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

• описание - текст описывающий функцию, составляется пользователем;

• имя файла - путь и имя файла функции;

• время создания функции;

• функция автомата - вызываемый метод;

• имя приложения - имя приложения которое эту функцию (выбирается из зарегистрированных в программе функций);

• иконка - путь и имя иконки для визуального представления функции в окне проекта;

• подпись - текст под иконкой функции в окне проекта;

• координаты функции в окне проекта;

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

• флаг запроса пользователя перед выполнением функции;

• указатели на исходящие функции OLE в проекте;

• указатели на входящие функции OLE в проекте;

• указатели на исходящие из функции документы;

• указатели на входящие в функцию документы;

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

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

• различные флаги устанавливаемые и снимаемые различными функциями и подпрограммами для разделения ресурсов выделенных программе;

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

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

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

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

1. Инструкция пользователя по работе с программой

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

После установки программы на диск ее можно запускать, для этого нужна лишь дважды щелкнуть на иконке программы или в главном меню Windows (“Пуск”) выбрать пункт “Выполнить” и изменить путь до исполняемого файла до запускаемого файла контроллера - Controller.exe и нажать кнопку “ОК”. После чего программа запустится и на экране появится главная форма программы (окно).

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

Основное окно программы состоит из рабочей области и меню, а также меню появляющееся при нажатии правой кнопки мыши (рис. 3.1).

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

Система ниспадающих меню позволяет оперативно управлять процессом проектирования. Меню “Файл” состоит из пунктов открытия проекта, сохранения проекта, открытие нового проекта, выхода из программы. Меню “Правка” позволяет посредствам буфера обмена информацией обмениваться информацией между проектами, а также изменять текущий проект, копировать объекты в буфер обмена и из него, удалять часть объектов (рис 3.2).

Меню “Создать” кроме непосредственно прямого выбора в линейке меню, через меню “Правка”, можно получить нажав правую кнопку мыши, из него можно выбрать объект (документ или функцию OLE, или зарегистрировать приложение OLE Automation) который необходимо создать. После выбора объекта запускается редактор свойств выбранного объекта (рис.3.3). Как видно из иллюстрации, в этих формах все свойства описаны непосредственно в форме.

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

Заполнив эти формы создается заданный объект который можно перемещать указателем мыши. Правой кнопкой мыши можно через возникшее меню всегда изменить свойства объекта (выбрав “Свойства”).

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

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

После работы с конкретным документом вырабатывается событие “Документ был изменен” которое должны обрабатывать все исходящие из документа функции OLE (если конечно у них был установлен флаг свойства “Автоматическое выполнение функции при изменении входного документа”). Что влечет за собой выполнение этих функций, то есть изменение документов исходящих из функции, что в свою очередь может повлечь за собой выполнение других функций. Процесс может стать циклическим (если входные документы будут изменены исходящими функциями). Чтобы этого не произошло необходимо пользоваться флагом “Запрос пользователя перед выполнением” в свойствах функции OLE. Установка этого флага повлечет собой запрос пользователю о необходимости выполнения этой функции перед ее выполнением. Тем самым предоставляется возможность пользователю зациклить процесс обратной связью, что иногда необходимо (например, для подбора нужного теплового режима), а затем прервать его.

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

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

1. КОНСТРУКТОРСКИЕ РАСЧЕТЫ

1. Показатели надежности

Основными конструкторскими расчетами для ЭВА, являются расчет надежности устройства и расчет прочности печатной платы. Рассмотрим теоретическое основание этих конструкторских расчетов.

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

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

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

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

Показатели надежности неремонтируемых систем базируются на понятиях функций надежности Р(t) и функции отказа Q(t), связанных зависимостью P(t) = 1- Q(t). Обе они зависят от времени t.

Вероятностью безотказной работы P(t) называют вероятность того, что в заданном интервале времени или пределах заданной наработки ti отказов в системе не возникает, т.е. P(ti) = P(T>ti), где Т - случайная величина характеризующая время наработки системы до возникновения в ней отказа. Соответственно вероятностью возникновения отказа в системе Q(ti) называется вероятность того, что в период наработки ti в ней обязательно произойдет отказ, т.е. Q(ti) = P(T< ti).

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

(4.1),

где

N1i - число изделий, отказавших во время испытаний на i-том интервале времени;

m = t / t - число интервалов

t - время испытания

t - продолжительность интервала времени

По аналогии с (4.1) статистическая вероятность безотказной работы ЭВА

(4.2),

Естественно, чем больше N, тем более точно соблюдается равенства, и тем точнее становятся значения величин P(ti) и P’(ti).

Вероятность безотказной работы может быть определена и для произвольного интервала времени (t1 ; t2), т.е. не с момента включения системы. В этом случае говорят об условной вероятности безотказной работы системы P(t1 ; t2) в период (t1 ; t2), имея в ввиду, что в момент времени t1 система находится в работоспособном состоянии. Условная вероятность P(t1 ; t2) определяется соотношением

P(t1 ; t2) = P(t2) / P(t1) (4.3)

где

P(t1) и P(t2) - соответственно значения функций надежности в начале и конце наработки.

Плотностью распределения наработки до отказа f(t) называют производную по времени от функции отказа Q(t):

(4.4)

Из (4.4) следует, что величина f(t)dt характерезует безусловную вероятность того, что система обязательно откажет в интервале времени (t ; t+dt) при условии что вмомент времени t она находилась в работоспособном состоянии.

Наиболее распространенным показателем надежности является интенсивность отказов. Интенсивность отказов (t) представляет собой условную вероятность возникновения отказа в системе в некоторый момент времени наработки при условии, что до этого момента отказов в системе не было. Величина интенсивности определяется отношением:(t) = f(t)/ P(t). Приблизительно ее можно оценить следующим отношением :

,

где

N1 - число изделий, отказавших при испытаниях в течении времени t

N - число изделий, работоспособных к началу испытаний.

Условная работоспособность системы в момент начала наработки можно записать в виде P(0) = 1. Тогда из (4.3) и (4.4) следует что

Аналогично может быть определена условная вероятность

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

В качестве показателя надежности используют среднюю наработку до отказа tcp. Средняя наработка до отказа представляет собой математическое ожидание M(t) случайной величины t

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

,

где

tcp i = (ti - ti-1) / 2

(ti ; ti-1) - время в начале и конце i-того интервала.

Таким образом мы рассмотрели основные показатели надежности систем./ 4 /

4.2. Методика расчета надежности

На практике чаще всего используется эскизный (ориентировочный) полный расчет надежности электронной аппаратуры. Расчет надежности нерезервируемой системы состоит в нахождении общей интенсивности отказов, наработки на отказ Тср и вероятности безотказной работы P(t). Эскизный расчет надежности нерезервированной системы можно проводить в следующем порядке :

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

2. по таблицам приведенным в /4/ определяют значения интенсивности отказов для элементов i-той группы;

3. рассчитывают интенсивность отказов системы как сумму произведений Ni, c учетом поправочного коэффициента

,

где

m - общее количество групп

k - поправочный коэффициент, учитывающий изменение средней интенсивности отказов элементов аппаратуры в зависимости от ее назначения (величина обычно табличная);

1. определяют наработку на отказ

;

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

;

Таким образом производится расчет надежности.

4.3. Методика определения механической прочности ПП

На ПП, как правило, устанавливается несколько десятков интегральных схем (ИС) и электроэлементов (ЭРЭ)

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

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

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

1. Определяем координаты Хi ,Yi, i-х элементов на плате - раастояние от осей до центра тяжести элементов (мм)

2. Определяем равнодействующую приложенных к плате сил

где

Рi - сила тяжести i-того элемента, Н;

к - количество элементов, шт.

1. Находим общий центр тяжести приложенных сил

и (4.5)

где

Xi и Yi - координаты центра тяжести платы, мм.

1. Определим силу. Действующюю на плату:

, (4.6)

где

а - ускорение, воздействующее на плату

1. Рассчитываем реакции в опорах :

(4.7) (4.8)

где

l - расстояние между опорами

1. Вычисляем максимальный изгибающий момент:

Mmax = RAXC (4.9)

1. Определяем крутящий момент крутящий момент :

Mk = Q d, (4.10)

где

d - величина смещения центра тяжести от оси симметрии платы

(4.11)

где

b - ширина платы

1. Находим напряжение, вызываемое в плате крутящим моментом :

(4.12),

где

h - толщина платы

- коэффициент прочности, равный 0.333.

1. Проверяем выполнение равенства

(4.13)

где

- максимально доупстимое напряжение в плате

Если неравенство (4.13) выполняется, то следует заключить, что приложенные нагрузки не приведут к повреждению платы. В случае, если неравенство (4.13) не выполняется, нужно предусмотреть меры, необходимые для дополнительного крепления платы.

4.3. Методика расчета собственных колебаний блока

Расчет частоты собственных колебаний блока можно привести, заменив конструкцию его эквивалентной расчетной схемой в виде блочной схемы /5/.

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

, (4.14)

где

а - длина пластины, м;

D - цилиндрическая жесткость пластины

, (4.15)

Е - модуль упругости;

- коэффициент Пуассона;

q - ускорение свободного падения;

- плотность материала

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

Для удобства пользования выражение (4.14) приведем к виду :

, (4.16)

где

В - частотная постоянная, зависщая от способа закрепления пластины

Если пластина не стальная, а выполнена из какого-либо другого материала, то в (4.16) вводится поправочный коэффициент kM на материал

где

Е и - модуль упругости и плотность применяемого материала;

ЕС и С - модуль упругости и плотность стали.

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

,

где

QЭ и QЭ - масса пластины и масса элементов, равномерно распределенных по пластине ;

Таким образом выражение (4.14) для определения частоты собственных колебаний приобретает вид

(4.17)

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

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

, (4.18)

где

jmax - вибрационные перегрузки

b - размер короткой стороны платы

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

4.5. Расчетная часть

В расчетной части проекта в качестве примера конструкторского расчета какой-либо конструкторской единицы представим конструкторский расчет платы усилителя импульсов (УИ).

5. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

1. Анализ безопасности труда конструктора оператора ЭВМ

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

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

Помещение машинного зала ВЦ представляет собой одну комнату (рис 5.1) площадью 42 кв.м. (7 x 6 М). В нем размещены 8 персональных компьютеров IBM (один из них занят под сервер), каждый из которых занимает один стол. Оператор занимает одно рабочее место у компьютера.

Следовательно, площадь одного индивидуального рабочего места равна 6 кв.м., что соответствует установленным санитарным нормам СНиП 4559-88 (не менее 6 кв.м.). В соответствии с нормами расстояние между торцами столов превышает 80 см, между столом и стеной или окном - 60 см, между длинными сторонами столов - 90 см.

Санитарные нормы СН 512-78 устанавливают высокие требования к микроклиматическим условиям в помещениях ВЦ:

Температура воздуха на рабочем месте

в теплый период года +20...+25 С

в холодный период года +18..+20 С.

Относительная влажность 40 - 60 % .

В помещениях ВЦ поддерживается слегка избыточное давление воздуха (приблизительно на 30 Па выше атмосферного) для препятствия попадания воздуха с пылью снаружи. Кроме того, при повышенном давлении воздуха улучшается отвод тепла от элементов ЭВМ.

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

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

Для помещения ВЦ характерно наличие различных видов шумов. Механический шум обусловлен работой вентиляторов кондиционеров и работой печатающих устройств.

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

Так как у современной вычислительной техники уровень собственных шумов значительно снижен (это не распространяется на печатающие устройства), общий уровень шума в помещении низок - порядка 50 дБ (что не превышает допустимой величены по ГОСТ 12.1.003-83) и специальные средства снижения шума не применяются.

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

(5.1),

где

k1 - коэффициент пропорциональности, характеризующий вероятность торможения электронов в электрическом поле ядра, k1=;

k2 = 1/Q, где Q- скважность пульсирующего напряжения,k2=1/4=0.25;

U - напряжение анода, U = 12кВ;

I - анодный ток, I = 5 мА ;

Z - атомный номер анода, Z = 14;

m - коэффициент поглощения излучения в воздухе, m = 10;

N - коэффициент ослабления излучения колбой ЭЛТ с сопротивлением проводящего слоя менее 12 Ом/см ,N=10;

R - расстояние от анода до рассматриваемой точки 5 см от стороны, обращенной к оператору плюс расстояние от анода до экрана, R=30см;

10 - эквивалент ватта (эрг/с);

0.114-эквивалент рентгена (эрг/см).

Подставив значения в формулу (5.1) получаем :

A/кг

Тогда как по ГОСТу 12.2.018-76 мощность экспозиционной дозы на расстоянии 5 см от экрана дисплея не более А/кг.

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

низкочастотное излучение - 50-60 Гц

трансформаторы блоков питания, электропроводка,

кадровая частота дисплеев;

частоты от 16 кГц до 4 МГц:

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

высокие частоты - от 8 до 25 МГц :

тактовые частоты процессоров.

Все источники электромагнитных излучений на рабочих местах в ВЦ ниже предельно допустимых значений напряженности (ГОСТ12.1.006-88). Однако, обслуживающий персонал находится под их воздействием длительное время, что вынуждает применять специальные средства экранировки дисплеев. Для этого используются специальные прозрачные экраны из тонкой металлической сетки.

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

Естественное освещение применено одностороннее боковое, общая площадь оконных проемов 5.04 кв.м. На окнах используются светлые светорассеивающие шторы.

Искусственное освещение обеспечивается 7-ю потолочными люминесцентными светильниками типа ШОД.

Режим работы нейтрали источника питания сети определяется системой энергоснабжения, принятой в месте расположения ВЦ. Сеть используется однофазная, напряжение 220 В. Для питания компьютера-сервера компьютерной сети установлен блок бесперебойного питания мощностью 600 Вт. Помещения ВЦ оборудованы контуром-шиной защитного заземления, электрически соединенной с заземлителем. Все подлежащие заземлению элементы ЭВМ присоединяются к контуру-шине отдельными заземляющими проводниками.

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

Наиболее неблагоприятным фактором, влияющим на оператора ЭВМ является психологическая нагрузка. / 6 /

5.2. Расчет освещенности

Для работы в лаборатории применяется совмещенный тип ос­вещения: боковое одностороннее естественное освещение в дневное время и общее искусственное в вечернее время.

Уровень освещенности согласно СНиП II-4-79 для зрительных работ высокой точности (от 0.3 до 0.5 мм) составляет : освещенность при боковом естественном освещении -2 %, освещенность при искусственном освещении -220 лк.

При боковом одностороннем освещении нормируется минимальное значение коэффициента естественного освещения (КЕО) в точке расположенной на расстоянии 1м от стены, наиболее удаленной от окон, на пересечении вертикальной плоскости характерного разреза помещения и условной рабочей поверхности или поля (рис 5.2).

Расчет естественного освещения заключается в определении площади световых проемов в соответствии с нормированным значением КЕО.

На основании СНиП II-4-79, приложение 5, рассчитываем площадь световых проемов при боковом освещении, при нормируемом КЕО =2%, по следующей формуле :

, (5.2)

где

S0-площадь световых проемов окон при боковом освещении, М2;

Sn-площадь поля освещения, Sn=42 М2;

lH-нормируемое значение КЕО, lH = 2;

k3-коэффициент запаса, k3 = 1.2;

h0- световая характеристика окон, h0 = 9.6 при двойном стекле;

k3Д- коэффициент затемнения окон противостоящими зданиями;

r0-общий коэффициент светопропускания окон, учитывающий коэффициент пропускания стекол;

r1-коэффициент, учитывающий повышение КЕО при боковом освещении благодаря свету, отраженному от поверхности помещения.

Согласно формуле (5.2) имеем :

,

откуда S0 = 5.04 М2;

Зная общую площадь световых проемов, рассчитываем размеры одного окна и их количество. Примем высоту окна равную 1.5 М, тогда общая длина окон составляет:

а = 5.04 / 1.5 = 3.36 M

отсюда при количестве окон N = 2 , длина каждого окна будет составлять :

b = 1.68 M

Из расчета видно, что для обеспечения естественного освещения, при нормируемом КЕО = 2 %, используются 2 окна размерами а = 1.5 и b = 1.68 ,что соответствует действительности в исследуемой лаборатории.

Для расчета исскуственного освещения найдем общий световой поток для лаборатории по формуле:

, (5.3)

где

r - коэффициент использования светового потока, r=0.4;

E min - наименьшая освещенность, E min = 200 лк;

k - коэффициент запаса, k = 1.5;

S-площадь помещения, S= 42 М 2 ;

Z- коэффициент перехода от наименьшей к средней освещенности, для светильников равномерного освещения Z=1.1;

Вычисляем показатель помещения:

, (5.4)

где

h - высота помещения, 3 М;

A и B -длина и ширина помещения, М.

Принимая коэффициент отражения от потолка PП = 70% и от стен PC = 50 %, по таблице определяем значение коэффициента r, как функции от PП , PC и j : r =1.2. Отсюда, общий световой поток равен (по формуле 5.3 ) :

лк

Определяем общее количество ламп:

шт.

Необходимое количество светильников определим по формуле:

шт.

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

1. Возможность чрезвычайных ситуаций

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

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

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

• либо падения какого-либо прибора;

• либо падения самого оператора;

• из-за взрыва кинескопа монитора (как самого взрывоопасного прибора в лаборатории).

Поражение электрическим током возможно по причинам:

• пробоя фазы на корпус прибора (которое может произойти как следствие броска напряжения в сети в сочетании с отсутствием заземления)

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

А возникновение пожара, в свою очередь, следует из наличия горючего материала в ВЦ и возникновения очага воспламенения. Очаг воспламенения может возникнуть в следствии следующих причин:

• курение оператора на рабочем месте, которое является следствием нервного перенапряжения в сочетании с нарушением техники безопасности;

• перегрева проводов в следствии перегрузки проводов током;

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

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

5.4. Пожарная безопасность

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

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

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

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

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

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

В соответствии со СНиП II-90-81 категорию производства по пожарной опасности можно отнести к группе В, так как в помещениях не производятся работы с легковоспламеняющимися жидкостями и горючими газами. Степень огнестойкости основных строительных конструкций лаборатории можно отнести к I степени согласно СНиП II-2-80.

5.5. Экологичность проекта

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

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

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

Работа с проектом, как в прочем и со всей вычислительной техникой, требует повышенного внимания со стороны человека, а по этому сопряжена с повышенным воздействием психофизиологических факторов (умственное перенапряжение, перенапряжение анализаторов, эмоциональные перегрузки и т.д.). Рекомендую, вследствие этого, изменить режим работы операторов. При этом применять более короткие, но частые перерывы в работе для физических упражнений. А также перерывы для психологической разгрузки (рекомендуется смена занятия, например применить динамические обучающие игры типа “Quake” или “Red Alert”).

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Microsoft Windows 95. Руководство пользователя/Под ред. Д.В. Егорова. М.: М.П.“Эрус”, 1996. - 153 с.

   
   

2. Лоуренс Харрис. Программирование OLE. Освой самостоятельно за 21 день. пер. с англ. - М.: Бином, 1995. - 464 с.

   
   

3. АРУШАНОВ Х.Р. Visual Basic 3.0, Visual Basic 4.0 для Windows. М.: Красный пролетарий, 1996. - 348 с.

   
   

4. Яншин А.А. Теоретические основы конструирования, технологии и надежности ЭВМ. М.: Радио и связь, 1983, 312 с.

   
   

5. Преснухин Л.Н., Шахнов В.А. Конструирование электронных вычислительных машин и систем. - М.: Высш. шк., 1986, -512 с.

   
   

6. Павлов С.П., Губонина З.И. Охрана труда в приборостроении: Учебник для вузов/ Под ред. А.Г. Алексаняна. -М.: Высшая школа, 1986.- 215 с.

ГОСУДАРСТВЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПО ВЫСШЕМУ ОБРАЗОВАНИЮ

ТАГАНРОГСКИЙ ГОСУДАРСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К ДИПЛОМНОМУ ПРОЕКТУ

Разработка программы контроллера автоматически связываемых объектов для управления конструкторской документацией в среде Windows 95/NT (дипломная_работа).              

Название

 ЦТРК 5.035.014ПЗ 

обозначение

   Сорокин Юрий Владимирович   

(фамилия, имя, отчество дипломника)

ФАКУЛЬТЕТ ЭЛЕКТРОНИКИ И ПРИБОРОСТРОЕНИЯ

КАФЕДРА КЭС

группа Э-92

ДАТА ЗАЩИТЫ 14>>  апреля  1997 г.