|
Контроллер связываемых объектов
Разработка программы контроллера автоматически связываемых объектов для
управления конструкторской документацией в среде Windows
95/NT. В данной дипломной работе осуществлена
разработка программного продукта, для среды операционной системы
, обеспечивающего создание, изменение и выполнение
функций автоматически связываемых объектов систем автоматизированного
проектирования или любых других пакетов прикладных и системных программ
поддерживающих механизм связывания и внедрения. Разработанный программный
продукт позволяет объединять функции автоматически связываемых объектов систем
проектирования в один проект с файлами данных этих систем проектирования, таким
образом являясь интеграционным звеном между различными программными
продуктами. В настоящее время на фоне всеобщей компьютеризации всех
производственных, торговых и бытовых отраслей с одновременным увеличением
конкуренции на компьютерном рынке, в связи с ускорением разработок все более
новых технологий производства вычислительной техники, все большее значение
приобретает разработка и производство конкурентоспособной вычислительной
техники. Сегодня это становится возможным только при использовании современных
средств проектирования электронных вычислительных средств (ЭВС). Современные
средства конструирования невозможно представить себе без компьютерных средств
проектирования. Компьютеры имеют большой потенциал в области проектирования ЭВС.
Компьютерные средства проектирования, кроме непосредственно компьютерного
оборудования, включают в себя программное обеспечение. На нынешнем этапе
развития программного обеспечения систем проектирования, имеется много
разработок систем автоматизации проектирования. Рынок программного обеспечения
насыщен большим количеством разнообразных пакетов прикладных программ включающих
в себя различные инструментальные средства, позволяющие во многом упростить
работу конструктора ЭВА. Сейчас у нас в стране и за рубежом наиболее
распространены такие пакеты программного обеспечения, как 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. Графические
операционные системы Наиболее распространенной средой программных
продуктов в настоящее время по праву является Windows, разработанная корпорацией
Microsoft в расчете на самый широкий круг пользователей. Windows предлагает
пользователю оконный интерфейс, в котором каждой выполняемой программе отводится
экранное окно которое может занимать часть экрана или весь экран. Программы,
специально спроектированные для таких оконных сред, могут пользоваться всеми их
преимуществами. Вид пользовательского экрана с перекрывающимися окнами различных
прикладных программ достаточно наглядно демонстрируют возможности среды по
одновременному использованию нескольких программ и передаче данных между ними
(рис. 1.1). Пользователь работает с приложением, находящимся самом "верхнем"
окне, но простым щелчком мыши на другом окне он может активизировать другую
программу. Кроме того, уже в своих ранних версиях Windows позволяла копировать
информацию из окна одной программы в окно другой программы при помощи средства
clipboard - буфера обмена. Графический режим 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 Windows 3.0
стал главным событием 1990 года на программном рынке, затмившим одновременное
появление IBM OS/2 1.3. Кроме приятного пользовательского интерфейса среда
Windows предоставляла значительный комплекс услуг. С системой поставлялось
большое количество драйверов для самых разных моделей устройств ввода-вывода,
таких как видеоадаптеры и принтеры. Широчайшая аппаратная совместимость была
одним из факторов успеха Windows. Комплект Windows 3.0 содержал несколько
вариантов драйверов для разных моделей клавиатур, мышей и видеоадаптеров и
большое количество драйверов принтеров. В Multimedia для Windows 3.0, а затем в
Windows 3.1 появились драйверы звуковых карт, МIDI устройств и синтезаторов.
Количество наименований поддерживаемых устройств быстро росло... С точки зрения массового пользователя, не
избалованного 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-
разрядных микропроцессорах. Чтобы запустить мотор
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 состоит из трех компонентов Kernel ,User и GDI. При
помощи дополнительных DLL-файлов (динамически загружаемых библиотек)
поддерживаются отображением стандартных диалоговых окон, протоколы DDЕ
(динамического связывания данных) и ОLЕ (связывания и встраивания объектов),
взаимодействие с драйверами устройств ввода-вывода и другие черты Windows.
Windows -драйверы устройств бывают, кстати, двух видов - "обычные" DLL-драйверы
и 386драйверы, последние предназначены опять-таки для работы только в 386-м
Расширенном режиме Windows. Наиболее низкоуровневой частью ядра Windows
является модуль Kernel, управляющий распределением памяти, процессами, файловым
вводом-выводом и так далее. В разных режимах работы Windows 3.О функции Kernel
выполняли различные файлы: kernel.ЕХЕ для Реального режима 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 выполнял аппаратно-независимые функции печати -
несколько десятков мини-драйверов, поставляемых производителями, дополняли
универсальный драйвер функциями обходимыми специально для поддержки конкретных
устройств и не повторяли уже написанный общий код. В 1996 году фирмой Microsoft , была выпушена следующая версия
операционной системы Windows. Которая была названа фирмой 32 разрядной
многозадачной графической системой. / 1 / Что
должна была сделать 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, имеет
трехуровневую структуру 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, мы
видим по большей части знакомые, хотя и серьезно улучшенные методы Windows 3.x.
Как показано на рис. 1.3., 16-разрядные приложения для Windows ("приложения
win16") выполняются в общем пространстве адресов в пределах системной
виртуальной машины. Такие варианты, как выполнение каждого приложения win16 в
отдельной виртуальной машине (что возможно в ОS/2) или полная эмуляция Windows
3.x в пределах операционной системы (как это делается в Windows NТ). 32-
разрядные приложения, созданные с учетом требований Windows 95 ("приложения
win32"), выполняются в режиме "подлинной" вытесняющей многозадачности. Кроме
того, Windows 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-разрядной адресацией, Соответственно объем
ресурсов Windows 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 обеспечивает: полную поддержку разнообразных звуковых плат, СD-ROM
приводов и других мультимедиа-устройств, не требуя при этом установки МS-DOS
драйверов; кэширование дисков, заменяя SMARTDrive; работу
с мышью не только в графической среде, но и с MS-DOS-программами, заменяя
драйвер мыши для MS-DOS; полную поддержку работы станции в
локальных сетях MS-NЕТ и Novell Netware, заменяя все резидентные программы,
которые приходилось загружать для работы в этих сетях. Windows 95
поддерживает текущую версию протокола Plug-and-Play. При установке
дополнительного устройства, подключаемого на основе Plug-and-Play, система сама
заботится о его конфигурировании. Достаточно удобно использовать Windows 95
и без аппаратной поддержки Plug-and-Play - система чрезвычайно много знает о
том, какие существуют внешние устройства и как идентифицировать, включая СD
дисководы, звуковые карты модемы, мыши и многое другое. Интерфейс Windows 95 соответствует требованиям самых
придирчивых пользователей, дизайнеров и специалистов по эргономике. На мой
взгляд, интерфейс Windows 95 великолепен, и перейти на эту систему стоило бы
даже в том случае, если бы новым в ней был только интерфейс. . Облик оболочки Explorer, основанный на
полноценном воплощении метафоры рабочего стола и папок, удобен и нагляден.
Панель задач дает полный обзор приложений, выполняемых системой в данный момент.
Доступ ко всем объектам, будь то программы, документы, сетевые ресурсы или
инструменты настройки системы, унифицирован. Имена любых объектов могут
содержать до 255 символов. . Оболочка Windows 95
предоставляет пользователю богатый и разнообразный выбор рабочих инструментов. В
качестве примера назову возможность создания так называемых ярлыков для быстрого
доступа к необходимым приложениям и документам, весьма удачное средство поиска
документов и встроенную программу быстрого просмотра документов различных
форматов. Выполнение многих действий, включая установку аппаратных компонентов,
отправку почтовых и факсимильных сообщений, установление связи между
компьютерами, автоматизировано при помощи специальных программ-мастеров .
Windows 95 можно настроить сотнями
способов, причем доступ к средствам настройки пользование ими весьма просты.
Windows 95 - это следующий шаг к
интеграции различных прикладных программ одну рабочую среду. Можно легко
создавать документы средствами оболочки, переносить данные из документа на
рабочий стол и в другой документ, выбрасывать в "мусорную корзину" фрагменты
текста, документы или целые папки, а при необходимости - возвращать их.
Справочная система Windows
стала удобнее и гибче. Многие разделы справки составлены в виде пошаговых
руководств с возможностью выполнения тех или иных рекомендуемых действий
непосредственно из системы помощи. Покинуть оболочку Windows 95 для работы с МS-DOS программами в реальном
режиме можно, только инициировав перезагрузку или отключение системы или же
перейдя в режим эмуляции МS-DОS (МS-DOS mode) с возможностью возврата в
графическую оболочку по команде ЕХIТ. Похоже, что нормальным состоянием Windows
95 действительно является графический интерфейс, который всегда находится где-то
под рукой, в памяти компьютера. Но это не так. В действительности "режим
эмуляции МS-DOS" представляет собой классическую МS-DOS, работающую в реальном
режиме и адресующую 640 Кбайт оперативной памяти. Графическая система Windows 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, а квалифицированный
пользователь, напротив, сможет применять как новые, так и старые, испытанные
методы работы с системой. Научно-технический прогресс 90-х годов обусловил неуклонный рост
популярности объектно-ориентированного программирования (ООП), и в настоящее
время многие программисты перешли в своей работе на С++ или Visual Basic. Уже
существуют объектно-ориентированные базы данных, объектно-ориентированные дизайн
и анализ и даже объектно-ориентированный СОВОL. На естественно возникающий
вопрос - не остались ли Windows или операционные системы в объектно-
ориентированном отношении далеко позади. Безусловно, нет. Продукт OLE ( Objekt
Linking and Embedding ) компании Microsoft открывает новые пути для применения
объектов в Windows. ОLE предполагает новый способ мышления. Программист в среде
ОПП должен мыслить обо всем как об объектах - от файла на диске, элемента данных
или приложения до аппаратного обеспечения и операционной системы. Кроме того,
OLE заставляет программиста следовать строгому набору правил, на зависящих от
языка программирования, операционной системы или даже от аппаратной платформы.
OLE служит основанием, на котором строятся объекты.
Эта аббревиатура означала изначально связывание и внедрение объектов (Objekt
Linking and Embedding) с выпуском версии ОLE 2 применение ОLE уже не
укладывается в рамках, связывания и внедрения. ОLЕ сегодня включает в себя
унифицированную передачу данных, структурированное хранилище информации и
автоматизацию. Не следует сужать представление об ОLЕ связыванием и внедрением;
смотреть на ОLЕ следует как на набор строительных блоков, позволяющих создавать
сложные приложения. На самом деле Microsoft перестала расшифровывать
аббревиатуру ОLE как Objekt Linking and Embedding, чтобы изменить сложившееся
восприятие ОLЕ.) / 2 / Если до появления
OLE 1 у пользователя Windows имелась электронная таблица, которую ему нужно было
вставить в документ текстового редактора, обыкновенно он должен был
экспортировать данные из таблицы в файл стандартного формата, импортировать
данные из файла в текстовый редактор, а затем в редакторе их переформатировать.
Если пользователю везло и оба приложения поддерживали копирование и вставку, то
вместо явного экспорта/импорта он мог копировать информацию через буфер
Clipboard. Всякий раз, когда электронные таблицы изменялись, процесс переноса
данных нужно было повторять. Это, естественно, приводило к лишней затрате
времени и сил. Но незадолго до выхода 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 - легких
удаленных процедурных вызовах). Чтобы достигнуть своих
задуманных функциональных возможностей, О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 Мбайт данных в оперативную память через буфер обмена объекту-клиенту
будет передан дескриптор данных, чтобы клиент сам мог их получить. Это избавляет
сервер от необходимости чтения всех данных и передачи их клиенту, а клиента от
необходимости самостоятельной обработки данных. Это также избавляет конечного
пользователя от сидения перед экраном компьютера в ожидании окончания обмена.
Связывание и внедрение
- два принципа, которые по традиции известны в OLE (Objekt Linking and
Embedding) лучше всего. Связывание и внедрение (вместо этого теперь говорят
просто о документах ОLЕ) позволяют объекту-клиенту (который может быть другим
приложением) прикрепиться к объекту-серверу. Присоединение может либо
осуществляться связыванием (данные находятся вне составного документа), либо
данные могут внедряться внутрь составного документа. Внедренные данные
сохраняются непосредственно в документе, в то время как при связывании для
доступа к данным OLE в действительности сохраняет своего рода дорожную карту.
Дорожной карта называется ярлыком (moniker). Когда ОLЕ получает запрос на
восстановления данных, оно смотрит на ярлык (дорожную карту), чтобы их отыскать.
Связанные данные могут храниться в не принадлежащем ОLЕ файле или в
структурированном хранилище (возможно даже, что данные находятся где-то в самом
составном документе). Составной частью связывания и внедрения является
способность OLE выполнять активацию по месту. В OLE 1 при двойном нажатии кнопки
мыши над связанным или внедренным объектом запускается сервер этого объекта. В
ОLЕ 2 возможна активация по месту. Для пользователя два приложения являются как
бы одним. Активация по месту присоединяет нужные части приложения сервера
(такие, как пункты меню и инструментальные линейки) к приложению клиента, когда
пользователь работает с внедренным объектом. При двойном нажатии кнопкой мыши
над внедренным объектом происходит преобразование приложения клиента, в нем
изменяются меню и линейки инструментов, а также прочие элементы интерфейса, для
работы с приложением сервера внедренного объекта. При двойном нажатии кнопкой
мыши над связанным объектом приложение сервер запускается в отдельном окне (как
в OLE 1). В терминах OLE описанное выше действие (двойное нажатие для
активации сервера) называется активацией извне (outside-in). При активации извне
сервер объекта не активируется (не запускается), пока пользователь не нажмет над
объектом кнопку мыши дважды. Активация изнутри (inside-out) требует, чтобы
объект-клиент активировал объект-сервер всегда, когда объект-сервер виден.
Сервер принимает управление по однократному нажатию кнопки мыши - потому, что
для активируемых изнутри объектов он уже запущен заранее. Сегодня в связи с все более ускоряющимися технологиями
программирования, постоянно повышаются требования к среде и к самому языку
программирования. Наиболее злободневные требования можно описать таким образом.
1. Отделение элементов программы, связанных с пользовательским интерфейсом от
алгоритмической части. Это позволяет минимизировать или вообще избежать при
правильном проектировании проекта изменений в алгоритмической части проекта при
модернизации пользовательского интерфейса вне зависимости от причин их
вызывающих: требование заказчика проекта по замене неверной надписи или
кардинальной смены концепции вследствие перевода разработок на другую платформу.
2. Простота и скорость создания/модернизации пользовательского интерфейса и
самих программ, путем использования уже готовых элементов (блоков), реализующих
некие крупные функции взаимодействия с человеком или другой программой. 3.
Еще раз простота, а также ясность и наглядность при программировании
пользовательского интерфейса, скрывающая нижний, сложный слой и оставляющая на
поверхности только малую, но самодостаточную необходимую часть айсберга
управления элементами интерфейса. При разработке
приложений для Windows вышеизложенным принципам очень удачно соответствует
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 / работа в среде
Windows 3.1, Windows для Рабочих Групп 3.11, Windows 95, Windows
NТ; расширение ТооlВох (Окно
Инструментария) за счет ОLЕ Insertable объектов; наличие новых и поддержка специализированных Data Bound
Control (объектов, значительно упрощающих работу с базами
данных); возможность разбиения длинных строк в
программном коде; запуск одновременно нескольких копий Visual Basic
4.0; создание 32-разрядных
приложений; .
Разработчик имеет возможность, используя директивы условной компиляции выбирать,
например, какую версию приложения (16- или 32-разрядную) он собирается создать.
Используя подобные директивы, можно создавать программы, имеющие один и тот же
исходный текст, но которые после компиляции смогут работать на различных
платформах. . Данное средство
предназначено для облегчения идентификации и управления всеми ОLЕ Automation
Servers, на которые есть ссылки в проекте. Выбрав нужный объект, разработчик
может легко выбрать и передать корректный синтаксис выражения работы с объектом
в текст программы или вызвать встроенную помощь для данного объекта.
Увеличена функциональны мощь встроенного
редактора. Во-первых, расширены возможности настройки, точнее постройки, "на
свой вкус" формата отображаемых строк кода, комментариев, ключевых слов,
идентификаторов, точек останова, и т. д. Можно задать различные фонты, цвета и
размеры фонтов для облегчения чтения текста программы. Во-вторых, улучшена
работа с отладочным окном. Больше нет необходимости держать и окно с
отлаживаемым текстом программы и окно с отображаемыми переменными - теперь
достаточно использовать одно окно, состоящее из двух подвижных частей: нижнее
подокно представляет собой полнофункциональный редактор кода, верхнее же
показывает содержимое переменных. Для объявления подпрограмм и функций, доступных или не
доступных из других модулей проекта, введены дополнительные служебные слова при
объявлении процедур: Public и Private соответственно. Visual Basic 4.0
"прихватил" теперь кусочек Pascal, добавив к своему лексическому запасу
выражения "With", "For Each", а также добавлены новые типы данных - Byte
(простое без знаковое, для представления чисел в диапазоне 0-255), Вооlean 16
битовые (2-байта) числа, которые могут принимать только два значения: True или
False) и Collection. Collection позволяет построить собственную группу
пронумерованных объектов. Использование Collection более предпочтительно, чем
использование массивов вследствие большей гибкости индексов, и наличия
наследуемых методов для вставляемых и удаляемых объектов
коллекции. Появилась
возможность создавать для объектов (форм, стандартных модулей и модулей классов)
собственные специализированные свойства (properties), и привязывать к ним
выполняемый код, который будет вызываться при обращении к свойству.
Оболочка разработки (IDE)
самого Visual Basic 4.0 также может быть управляем через ОLЕ Automation, что
позволяет ОLЕ приложениям создавать и размещать в специальное меню Add-In Visual
Basic 4.0 свои команды, расширяя таким образом возможности IDE. Одной из основных претензий к
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
Excel для Windows, Microsoft Word для Windows и другие, являющиеся ОLЕ
приложениями, теперь можно вставлять в Окно Инструментария (ТооlBох) как обычные
элементы управления. 2. РАЗРАБОТКА
СТРУКТУРНОЙ СХЕМЫ И АЛГОРИТМОВ ПРОГРАММЫ Операционная система должна обеспечивать взаимодействие
приложения как самой верхней ступени с самым нижним уровнем иерархии -
аппаратной частью компьютера, через набор каких-либо стандартных функций и
подпрограмм. Кроме того она должна обеспечивать пользователя удобным
интерфейсом. Рассмотрим как это реализовано в выбранной операционной системе
Windows 95. Функциональная схема работы операционной системы Windows 95
представленная на рис 2.1. Аппаратная часть компьютера представляющая собой
какие-либо устройства ввода-вывода информации (клавиатура, мышь, принтер,
плоттер, сканер, устройство чтения компакт дисков, монитор и т.д.) подключена на
системную шину через так называемые контроллеры устройств имеющие в адресном
пространстве памяти вычислительной машины какие-то адреса называемые портами
ввода-вывода. Через эти порты при низкоуровневом программировании программист
может обмениваться информацией с устройством. Но сейчас такая технология
считается устаревшей и приводящей к излишним затратам ресурсов. Ведь в таком
случае стандартные функции обмена информацией должны находится в каждой
программе которая могла обмениваться информацией с внешними устройствами.
Windows 95 обеспечивает взаимодействие с внешними устройствами как с потоками
информации независимо от самого устройства через свои собственные драйвера
устройств. Итак, устройства обмена информацией подключаются к компьютеру через
контроллеры, которыми управляют драйверы устройств. Драйверы устройств
разработаны таким образом, что при передаче информации на устройство они
организовывают очередь следуя которой на устройство передается информация от
различных приложений (например принтер). Однако при передаче информации в
обратном направлении (от устройства) драйверы создают так называемые события
(например событие "закончена печать" от принтера или "нажата кнопка" от мыши),
которые операционной системой помещаются в глобальную очередь событий, из
которой события попадают в специальный блок определения назначения события. Там
по информации хранящейся в системе: приоритет события, какое приложение открыло
поток обмены с устройством, приоритет приложения открывшего поток обмена и пр.
Определяется назначение события, его принадлежность определенной виртуальной
машине организованной системой. По этому назначению передается сообщение о
происходящем событии приложению которое должно его обработать. В отдельной
виртуальной машине приложения по приходе событий организовывается локальная
очередь событий. Из которой сообщения о событиях передаются по так называемому
фокусу объекту который в этот момент находится в фокусе. Объектом может быть
любой элемент управления (как то кнопки, поля ввода, имиджи, иконки, картинки и
т.д.). С объектом связана целая система процедур и функций которые могут
обрабатывать события приходящие объекту, а также могут передавать их другим
объектам или выше на ступень по иерархии объектов (элементы управления
передавать формам, а формы в свою очередь более глобальным формам или окнам
приложений или самой системе). Таким образом, задача программиста заключается
в создании подпрограмм и функции реагирующих определенным образом на события
приходящие от системы, для всех объектов которые могут использовать эти события
в целях определяемых программой в целом, для конкретной задачи поставленной
перед программой. Итак, Visual
Basic предназначен для быстрого создания приложений в среде Windows, и как любая
программа для Windows, программа, написанная на Visual Basic, должна иметь как
минимум одно окно. В терминах Visual Basic все окна есть формы, в программе
может быть множество окон-форм. Формы в программе служат для отображения
элементов пользовательского интерфейса. На каждой форме может находится
некоторое количество элементов управления, а также графика и даже другие формы,
причем, как вырожденный случай, на форме может вообще не располагаться ни одного
элемента. В том случае, когда приложение использует окно-форму для отображения
различных типов информации или предоставляет возможность работать в нескольких
режимах, чтобы не засорять площадь окна множество дополнительных элементов,
используется линейка ниспадающих меню. Каждое меню содержит список пунктов,
которые в свою очередь могут разворачиваться в подменю. Названия подобных
вложенных подменю, а также пунктов меню, при выборе которых потребуется в
отдельном диалоговом окне выполнить некие дополнительные действия, при
отображении в списке пунктов меню дополняются справа многоточием. Элементы
управления служат для отображения информации, выбора из некоторого множества
объектов, а также для более ясного и четкого восприятия. Любая, даже
простейшая программа на Visual Basic, имеет свой Проект (project), информацию о
котором хранится в специальном файле. В проект программы, отображаемом в
специальном окне Проекта, помещаются все формы, модули и файлы, совокупность
которых и составляет программу. Visual Basic не является объектно-
ориентированным языком в догматическом понимании ООП (объектно-ориентированное
программирование), Visual Basic базируется на парадигме событийно-
ориентированного программирования: программа - суть некий набор реального или
виртуального мира, каждый из которых понимает некий ограниченный набор событий
(возможна, расширяемый). По приходу каждого события из набора отслеживаемых
событий формы и элементы управления могут реагировать определенным образом, в
соответствии с программным кодом, реализованным программистом для каждого
объекта. Для внесения управляющего программного кода для событий и методов
используется Редактор Кода, который служит для создания, просмотра и модификации
подпрограмм (Sub) и функций (Function). Процедура представляет собой
подпрограмму, которая не возвращает результата. Программный код, связанный с
формами и элементами управления, служит для реализации ответной реакции
программы на действия пользователя или приход системного события. Программный
код может находиться в специальных программных модулях (стандартные модули и
модули классов) или быть "привязан" только к элементу управления (то есть
объекту) или форме. Кроме набора событий (events), для каждого элемента
управления существует предопределенный (возможно, расширяемый) набор свойств или
характеристик (properties), представляющих собой некие начальные установки.
Данные свойства разделяются по сфере доступности: есть свойства, которые могут
устанавливаться только в режиме разработки, только во время выполнения программы
или в обоих случаях. Установка и настройка свойств объектов осуществляется в
окне Свойств (Properties). Для элементов управления и форм также существует
связанный с ними набор методов (method), которые можно рассматривать как набор
команд, понимаемых данным объектом. Для некоторых отображаемых на экране
элементов управления есть возможность задавать различные основные цвета и цвета
фона. Для удобства выбора нужных цветов используется Цветовая Палитра (Color
Palette). Таким
образом переходя к синтезу структурной схемы программы можно условно разбить на
несколько логических блоков. Каждый из которых представляет собой набор
привязанных к объектам подпрограмм, функций и данных (рис. 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 и приложений, а также
расшифровка ответных сообщений системы и программ. Для более качественной разработки алгоритма взаимодействия программы с
механизмом связывания и внедрения объектов 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 взаимодействия. Разработка
структуры данных Приступая к разработке структуры данных необходимо
разделять данные по критерию возможности доступа до них. Так данные применяемые
только в форме должны находится в самой форме, а данные доступ до которых
происходит из нескольких форм называются глобальными и обычно помещаются в
модуль с применением префикса Public (для возможности доступа до них из
вне). В этом разделе будет описана структура данных из главного модуля
программы в котором хранятся глобальные данные необходимые для всего
проекта. Модуль состоит из четырех частей (рис. 2..5), три из которых
представляют собой структуры для представления в машинном виде данных о
регистрированных приложениях, о документах находящихся в проекте и о функциях
применяемых в проекте для работы с документами. В четвертой части находятся
данные необходимые для взаимодействия между формами, и нормальной работы
контроллера в целом. глобальный номер регистрации - представляет собой
сквозную нумерацию всех когда либо зарегистрированных приложений не зависящею от
количества установленных и удаленных приложений на данный конкретный момент
времени; имя файла - указатель на запускаемый файл приложения
для работы с ним блока OLE Automation; имя приложения - собственное
расширенное имя приложения указываемое для удобства работы с программой;
маска файлов - одно или несколько расширений имен файлов документов
с которыми может работать зарегистрированное приложение. глобальный номер документа - представляет собой сквозную
нумерацию всех когда либо созданных документов не зависящею от количества
созданных и удаленных документов на данный конкретный момент
времени; имя файла - путь и имя файла
документа; имя приложения - имя
приложения которое обрабатывает этот документ (выбирается из зарегистрированных
в программе приложений или стандартный обработчик Windows документа с таким
расширением) ; подпись - текст под иконкой
документа в окне проекта; указатели на исходящие из документа функции OLE в
проекте. Наиболее объемными являются данные о функциях OLE
содержащихся в проекте, состоящие из следующих переменных: глобальный
номер функции - представляет собой сквозную нумерацию всех когда либо созданных
функций не зависящею от количества созданных и удаленных функций на данный
конкретный момент времени; имя файла - путь и имя файла
функции; имя приложения - имя приложения которое эту функцию
(выбирается из зарегистрированных в программе функций); подпись - текст под иконкой функции в окне
проекта; флаг
автоматического выполнения функции в случае изменения любого входящего в из
функцию документа; указатели на исходящие функции OLE в
проекте; линковщик документов и функции - строка связывающая
документы и функцию в одну строку используемую программой в качестве вызова
функции с параметрами. Четвертая общая часть состоящая из различных
переменных необходимых для работы всей программы состоит из
следующего: различные флаги устанавливаемые и снимаемые различными
функциями и подпрограммами для разделения ресурсов выделенных
программе; глобальные переменные определяющие количество документов,
функций OLE и зарегистрированных приложений на данный момент
времени; переменные обмена информации (определяющие состояние буфера
обмена и структуру данных находящихся в буфере обмена). Таким
образом определены все данные необходимые для работы всей программы в целом.
Кроме того в каждой отдельной форме существует область объявления переменных, в
которой определяются переменные для работы конкретно этой формы. Существуют
также и области объявлений переменных в каждой отдельной функции и подпрограмме
для работы этой функции. Такое разделение областейвидимости позволяет более
гибко управлять данными в программе. Перед запуском программы контроллера программу необходимо
инсталлировать ее на жесткий диск. Это может выполнить как специальная программа
инсталляции, так и сам пользователь. Нужно установить саму программу в
специальную директорию, а специальные 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
самостоятельно. Список всех файлов программы приведен в
приложении. Основными конструкторскими расчетами для ЭВА, являются расчет
надежности устройства и расчет прочности печатной платы. Рассмотрим
теоретическое основание этих конструкторских расчетов. Все промышленные
изделия характеризуются качеством, то есть совокупностью свойств, которые
отличают данное изделие от других и определяют степень его пригодности для
эксплуатации по своему назначению. Для ЭВА это прежде всего совокупность
конструкторских, технологических и эксплутационных характеристик. В процессе
эксплуатации происходят изменения этих характеристик в следствии износа и
необратимых процессов старения. Таким образом меняется качество изделию во
времени, а характеристикой изменения качества во времени является показатель
называемый надежностью. Под надежностью понимают свойство изделия выполнять
заданные функции, сохранять свои эксплутационные показатели в заданных пределах
в течении требуемого промежутка времени или требуемой наработки при соблюдении
режимов эксплуатации, правил обслуживания, хранения и т.д. Надежность не может
быть измерена непосредственно как любая физическая величина. Она может быть
только количественно оценена или предсказана. Для оценки основных показателей
надежности используют математический аппарат теории вероятности Показатели
надежности неремонтируемых систем. Неремонтируемые системы работают до первого
отказа после чего заменяются новыми. Все количественные показатели надежности
неремонтируемых систем являются общими и выражаются одними и теми же
математическими зависимостями, но их конкретные числовые значения зависят от
режимов работы изучаемых систем. Показатели надежности неремонтируемых систем
базируются на понятиях функций надежности Р(t) и функции отказа Q(t), связанных
зависимостью P(t) = 1- Q(t). Обе они зависят от времени t. Вероятностью
безотказной работы P(t) называют вероятность того, что в заданном интервале
времени или пределах заданной наработки t ), где Т - случайная
величина характеризующая время наработки системы до возникновения в ней отказа.
Соответственно вероятностью возникновения отказа в системе Q(t в ней
обязательно произойдет отказ, т.е. Q(t Теоретическое значение вероятности безотказной работы ЭВА
удобно определить следующим образом : - число изделий, отказавших во время испытаний на
i-том интервале времени; t -
продолжительность интервала времени Естественно, чем больше N, тем более точно соблюдается равенства, и
тем точнее становятся значения величин P(t Вероятность безотказной работы может быть определена и для
произвольного интервала времени (t ), т.е. не с
момента включения системы. В этом случае говорят об условной вероятности
безотказной работы системы P(t 1 ) определяется соотношением
2 Плотностью распределения
наработки до отказа f(t) называют производную по времени от функции отказа
Q(t): Из (4.4) следует, что величина f(t)dt характеризует безусловную
вероятность того, что система обязательно откажет в интервале времени
(t;t+dt) при условии что в момент времени t она находилась в
работоспособном состоянии. Наиболее распространенным показателем
надежности является интенсивность отказов. Интенсивность отказов (t) представляет
собой условную вероятность возникновения отказа в системе в некоторый момент
времени наработки при условии, что до этого момента отказов в системе не было.
Величина интенсивности определяется отношением: (t) = f(t)/ P(t).
Приблизительно ее можно оценить следующим отношением : - число изделий, отказавших при испытаниях в
течении времени N - число изделий, работоспособных к началу испытаний.
Условная работоспособность системы в момент начала наработки можно записать в
виде P(0) = 1. Тогда из (4.3) и (4.4) следует что Аналогично
может быть определена условная вероятность Таким образом
мы рассмотрели три показателя надежности. Очевидно, что достаточно знать одну
(любую) из них, чтобы определить два других. Таким образом все три показателя
являются равноправными. Однако в большинстве случаев предпочтение отдают
интенсивности отказов. . Средняя наработка до отказа представляет
собой математическое ожидание M(t) случайной величины t Вид функций f
(t) и P (t) определяется конкретными законами распределения случайной величины
t. Средняя наработка до отказа - это ожидаемое время исправной работы системы до
первого отказа. Приближенно ее можно оценить так: - t Таким образом
мы рассмотрели основные показатели надежности систем./ 4 / На практике чаще всего используется
эскизный (ориентировочный) полный расчет надежности электронной аппаратуры.
Расчет надежности нерезервируемой системы состоит в нахождении общей
интенсивности отказов, наработки на отказ Т и вероятности
безотказной работы P(t). Эскизный расчет надежности нерезервированной системы
можно проводить в следующем порядке : все элементы системы разбиваются
по группам с одинаковыми или близкими интенсивностями отказов и подсчитывается
число элементов N в каждой i-той группе; по таблицам приведенным в
/4/ определяют значения интенсивности отказов рассчитывают интенсивность отказов системы как сумму
произведений N c учетом
поправочного коэффициента m -
общее количество групп k - поправочный коэффициент, учитывающий изменение
средней интенсивности отказов элементов аппаратуры в зависимости от ее
назначения (величина обычно табличная);
; Таким
образом производится расчет надежности. На ПП,как правило, устанавливается несколько
десятков интегральных схем (ИС) и электроэлементов (ЭРЭ) , необходимо проверить, не приведут
ли эти воздействия к возникновению недопустимых напряжений на плате Величина
предельно допустимого напряжения G задана. При воздействии на плату нагрузки с
ускорением, на нее будет действовать деформация изгиба и кручения. Для расчета
возникающих напряжений плату принято представлять в виде балочной системы,
лежащей на опорах. i Определяем равнодействующую приложенных к плате сил - сила тяжести i-того элемента, Н; и i
а - ускорение, воздействующее на плату (4.7) l - расстояние между опорами Определяем крутящий момент крутящий момент : Находим напряжение, вызываемое в плате
крутящим моментом : Проверяем выполнение равенства Если неравенство (4.13)
выполняется, то следует заключить, что приложенные нагрузки не приведут к
повреждению платы. В случае, если неравенство (4.13) не выполняется, нужно
предусмотреть меры, необходимые для дополнительного крепления
платы. Расчет частоты собственных колебаний блока можно привести, заменив
конструкцию его эквивалентной расчетной схемой в виде блочной схемы
/5/. Частоту собственных колебаний прямоугольной пластины для всех случаев
закрепления ее краев можно определить следующим образом : а - длина пластины, м;
, (4.15) коэффициент
Пуассона; - плотность
материала - коэффициент,
значение которого зависит от способа закрепления сторон пластины
В - частотная постоянная, зависящая от способа закрепления
пластины Если пластина не стальная, а выполнена из какого-либо другого
материала, то в (4.16) вводится поправочный коэффициент k Е и - модуль упругости и плотность применяемого
материала; -
модуль упругости и плотность стали. - масса пластины и масса элементов, равномерно
распределенных по пластине ; Важно,
чтобы резонансная частота ПП отличалась от частоты вынужденных колебаний на
входе, по крайней мере в два раза. При этом исключается вхождение в резонанс,
опасный в вибросистеме. Печатная плата должна обладать значительной
усталостной долговечностью при воздействии вибраций, для этого необходимо, чтобы
минимальная частота собственных колебаний платы удовлетворяла условию: - вибрационные перегрузки -
безразмерная постоянная, числовое значение которой зависит от значений частоты
собственных колебаний и воздействующих ускорений. В расчетной части проекта в качестве примера конструкторского
расчета какой-либо конструкторской единицы представим конструкторский расчет
платы усилителя импульсов (УИ). '***************************** Public SelectOn As
Boolean Public TotalDocCo As Integer Public CurFunction As Integer Discription
As String Public Registrations() As RegistrationType CreateDateTime As String Y As Integer OutputDocPointCo
As Integer TotalNumber As Long AutomatFunction As String ImageText As
String InputDocPointCo As Integer InputFunPointCo As Integer Public FunctionCo As Integer
MakeDocForm.Label4(0).Caption = FileLen(Documents(DocNumber).FileName)
MakeDocForm.Label4(2).Caption = Documents(DocNumber).CreateDateTime
MakeDocForm.Icon9412_.Picture = LoadPicture(Documents(DocNumber).ImageIcon)
MakeDocForm.Discrip.Text = Documents(DocNumber).Discription MakeDocForm.Combo1.ListIndex =
RegistrationCo + 1 Err1: Public Sub SaveRegCards() Open App.Path
& "\RegisterCards" For Output As FileNumber Write #FileNumber, .TotalNumber, .Discription, .FileName,
.NameApp, .FileMask & Chr(13) & Chr(10) & Err.Number & Chr(13) &
Chr(10) & _ End Select Documents(DocNumber).ImageText =
MakeDocForm.IconText.Text Documents(DocNumber).Discription =
MakeDocForm.Discrip.Text Documents(DocNumber).CreateDateTime =
MakeDocForm.Label4(0).Caption
Documents(DocNumber).UsedProgramm =
Registrations(MakeDocForm.Combo1.ListIndex).TotalNumber Dim a As Integer Write
#FileNumber, TotalDocCo, TotalFunCo, DocumentCo, FunctionCo Write #FileNumber, .TotalNumber, .FileName,
.CreateDateTime, .UsedProgramm, _ For b = 0 To
.OutputFunPointCo Write #FileNumber, .OutputDocPoints(b) Write
#FileNumber, .TotalNumber, .FileName, .CreateDateTime, .UsedProgramm, _ .ImageIcon,
.ImageText, .X, .Y, .DocumentsAndFunctionsLink, _ Write #FileNumber, .OutputFunPoints(b)
For b = 0 To .InputFunPointCo Write #FileNumber, .InputDocPoints(b) &
Chr(13) & Chr(10) & Err.Number & Chr(13) & Chr(10) & _ End Select FileNumber = FreeFile If
RegistrationCo = -1 Then With
Registrations(a) Close FileNumber Err.Description, vbAbortRetryIgnore + vbCritical) Dim a As Integer
Input #FileNumber, TotalDocCo, TotalFunCo, DocumentCo, FunctionCo Input #FileNumber, .TotalNumber, .FileName,
.CreateDateTime, .UsedProgramm, _ If .OutputFunPointCo <> -
1 Then Input #FileNumber, .OutputFunPoints(b) For b = 0 To .OutputDocPointCo If FunctionCo <> -1 Then Input #FileNumber, .TotalNumber,
.FileName, .CreateDateTime, .UsedProgramm, _ .ImageIcon, .ImageText, .X, .Y,
.DocumentsAndFunctionsLink, _ If .OutputFunPointCo <> -1
Then Input #FileNumber, .OutputFunPoints(b) For b = 0 To .OutputDocPointCo ReDim .InputFunPoints(.InputFunPointCo)
If .InputDocPointCo <> -1 Then Input
#FileNumber, .InputDocPoints(b) & Chr(13) & Chr(10) &
Err.Number & Chr(13) & Chr(10) _ Case vbIgnore Public Function GetREGIndex(TotalNumber As Long) As
Integer GetREGIndex = a Dim a As Integer
End If For a = 0 To FunctionCo End Function ImageCo = ImageCo +
1 .ImageIcon(ImageCo).Visible =
True .ImageIcon(ImageCo).Tag =
Documents(a).TotalNumber .ImageText(ImageCo).Left =
Documents(a).X .ImageText(ImageCo).Caption =
Documents(a).ImageText '******************************
Dim a As Integer For a = 0 To ImageCo
Documents(GetDOCIndex(ImageIcon(a).Tag)).X = ImageIcon(a).Left + dX
ImageIcon(a).Left = ImageIcon(a).Left + dX
ImageText(a).Top = ImageIcon(a).Top + 500 Documents(GetDOCIndex(Source.Tag)).Y = Y
ImageText(Source.Index).Top = Y + 500
MakeDocForm.Combo1.Clear
MakeDocForm.Combo1.AddItem "Использовать стандартный обработчик", RegistrationCo
+ 1 LoadProject App.Path & "\pro1.prj" Private Sub
Form_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single) .Height = 0 Private Sub Form_MouseMove(Button As
Integer, Shift As Integer, X As Single, Y As Single) .Top = MouseY .Left = MouseX Private Sub
Form_MouseUp(Button As Integer, Shift As Integer, X As Single, Y As Single) MenuMake.Visible = True If SelectIs =
True Then MenuDelete.Visible = False MainForm.PopupMenu RightButtonMenuOnForm If (ImageIcon(a).Top > selectrec.Top) And _ (ImageIcon(a).Top <
(selectrec.Top + selectrec.Height)) And _
ImageIcon(a).BorderStyle = 1 Private Sub Form_Unload(Cancel As
Integer) Private
Sub ImageIcon_MouseMove(Index As Integer, Button As Integer, Shift As Integer, X
As Single, Y As Single) Private Sub ImageIcon_MouseUp(Index As Integer, Button As
Integer, Shift As Integer, X As Single, Y As Single) MenuPropertyes.Visible = True Private Sub
Menu_Edit_Click() If SelectIs = True
Then Else TotalDocCo = TotalDocCo + 1
MakeDocForm.Label4(1).Caption = str(Now)
MakeDocForm.Icon9412_.Picture = LoadPicture(App.Path & "\DefDoc.ico") MakeDocForm.DocumentName = ""
DocumentCo = DocumentCo - 1 MemberDocumentProperty
DocumentCo
Documents(DocumentCo).OutputDocPointCo = -1
ImageIcon(ImageCo).Left = Documents(DocumentCo).X ImageIcon(ImageCo).Picture =
LoadPicture(Documents(DocumentCo).ImageIcon)
ImageText(ImageCo).Top = Documents(DocumentCo).Y + 300 ImageText(ImageCo).Enabled = True ImageText(ImageCo).Tag = 1 '****************
1 = Это документ If ImageText(MenuFrom).Tag =
1 Then MemberDocumentProperty temp
ImageIcon(MenuFrom).Picture = LoadPicture(Documents(temp).ImageIcon) End Sub If ImageText(Index).Tag = 1 Then Next a Next
a ShowProject Private Sub Cancel_Click() RegDialog2.Flags = cdlOFNHideReadOnly RegDialog2.Filter = "Âñå
ôàéëû*.*" & _ RegDialog2.Filter =
"Âñå ôàéëû*.*" Private Sub Command2_Click()
Icon9412_.Picture = LoadPicture(RegDialog.FileName)
DocumentIsChanged = True Dim
ErrorFlag As Boolean If DocumentName.Text = "" Then tmp = FileLen(DocumentName.Text) End If Select Case
MsgBox("Ïðîèçîøëà
îøèáêà íîìåð :" &
Err.Number & _ Case vbRetry ' registration form
code On Error GoTo Err1 Err1: ShowRegCard
Combo1.ListIndex LSet Registrations(a)
= Registrations(a + 1) ReDim Preserve Registrations(RegistrationCo) Combo1.ListIndex = CurIndex Private Sub Form_Activate() CardShow CurIndex
RegistrationCo = RegistrationCo + 1 Registrations(RegistrationCo).NameApp =
InputBox("Ââåäèòå èìÿ
ïðèëîæåíèÿ", ,
"Ïðèëîæåíèå" +
str(RegistrationCo + 1)) TotalRegCo = TotalRegCo
- 1
Registrations(RegistrationCo).TotalNumber = TotalRegCo str =
InputBox("Ââåäèòå èìÿ
ïðèëîæåíèÿ", ,
Registrations(a).NameApp) Combo1.AddItem
Registrations(a).NameApp, a Browser.Enabled
= False Discrip.Enabled = False Label2.Enabled = False Browser.Enabled = True
Label1.Enabled = True Public Sub CardShow(NumRegCard As
Integer) Discrip.Text =
Registrations(NumRegCard).Discription Registrations(CurIndex).FileMask = ListExt.Text Рис. 3.2. Меню "Правка"
| |
