Содержание к диссертации
Введение
Глава 1, Анализ развития промышленных программных систем 13
1,1 Гибкость и расширяемость программного обеспечения 14
1.1.1. Программные комплексы, создаваемые на заказ 16
1.1.2. Тиражные программные комплексы 17
1.2. Подсистемы программирования 19
1.2.1. Этапы развития 19
1.2.2. Недостатки первых подсистем программирования 22
1-2.3. Механизмы взаимодействия приложений в операционных средах Microsoft Windows 23
1,2.4. Интеграция с компонентной архитектурой Microsoft ActiveX 26
1.3. Параллельные и распределенные вычисления 35
1.4. Выводы по главе 1 38
Глава 2, Технология построения контейнеров управляющих элементов ActiveX 39
2.1. Общие принципы создания ActiveX-контейнеров 41
2.2. Архитектурные решения 43
2.2.1. Устройство объекта контейнера 43
2.2.1.1. Класс CAxContLight 45
2.2.1.2. Класс CAxContBase 46
2.2.1.3. Класс CAxFormBase 51
2.2.1.4. Класс CForm 55
2.2.2. Устройство объекта связи с управляющим элементом 57
2.2.2.1. Классы CChildAxii CChildAxCreator 57
2.2.2.2. Класс CAxSiteBase 58
2.2.2.3. Класс CAxFormSiteBase 63
2.2.2А Класс CSite 64
2.2.3, Устройство объекта расширенного управляющего элемента 65
2.2.3.1, Класс CAxItemBase 65
2.2.3.2. Класс CItem 67
2.2.4, Подходы к использованию библиотеки 67
2.3, Автоматизация процесса разработки ActiveX-контейнера 70
2.4. Выводы по главе 2 75
Глава 3, Методы обнаружения исключительных ситуаций 76
3.1. СП-метод 77
3.1.1. Пример использования 78
3.2АОметод 83
3.2.1. Пример использования 84
3.3, Сравнительный анализ представленных методов 88
3.4, Метод обнаружения исключительных ситуаций в №іп32-приложениях . 90
3.4.1. Теоретическое обоснование 91
3.4.1.1 Операционная семантика функции CreateThread 92
3.4.1.2. Операционная семантика критических секций 93
3.4.1.3. Операционная семантика функции WaitForSingleObject 94
3.4.1.4. Операционная семантика функции WaitForMultipleObjects 94
3.4.1.5. Операционная семантика семафоров 95
3.4.1.6. Операционная семантика событий 96
3.4.1.7. Операционная семантика мьютексов 97
3.4.2. Пример работы 100
3.5- Выводы по главе 3 103
Глава 4, Инструментальный комплекс RS-Forms 104
4.1. Архитектура приложений RS-Forms 105
4.2. Структура RS-Forms 106
4.3. Средства разработки RS-Forms 108
4.3.1 Особенности Дизайнера RS-Forms 109
4.3.2. Генератор кода 110
4.3.3. Редактор исходного кода 111
4.3.4. Особенности экранных форм 112
4.3.5. Механизм вывода информации на печать 113
4.3.6. Компонентный подход 117
4.3.7. Настраиваемые элементы управления 119
4.3.8. Окна в RS-Forms 120
4.3.9. Особенности меню в RS-Forms 120
4.3.10. Связь форме данными 122
4.3.11. Редактор списков иконок 122
4.4. Компоненты RS-Forms, созданные на основе предложенной технологии построения ActiveX-контейнеров 123
4.4.1. Контейнер - оконная оболочка для одного ActiveX-элемента 123
4.4.2. Управляющий элемент "форма" 124
4.4.3. Управляющий элемент "печатная страница 125
4.4.4. Управляющий элемент "табулятор" 126
4.4.5. Объект "меню" 126
4.4.6. Представление форм в виде самостоятельных управляющих элементов ActiveX 127
4.5. Выводы по главе 4 131
Заключение 132
Литература 133
Приложение
- Механизмы взаимодействия приложений в операционных средах Microsoft Windows
- Устройство объекта связи с управляющим элементом
- Метод обнаружения исключительных ситуаций в №іп32-приложениях
- Компоненты RS-Forms, созданные на основе предложенной технологии построения ActiveX-контейнеров
Введение к работе
Актуальность проблемы. Особенностью создания крупных программных комплексов является включение в их состав подсистем программирования, предназначенных для решения задач настройки и адаптации комплекса для конкретных условий его применения. Наличие таких подсистем позволяет расширять функциональные возможности комплекса в ходе его промышленной эксплуатации.
Большинство подсистем программирования, поставляемых с ориентированными на исполнение в операционных средах Microsoft Windows зарубежными информационными системами, построены на основе технологии Microsoft ActiveX. В то же время инструментальные средства, интегрированные в отечественные комплексы, по существу, не поддерживают указанную технологию. Это приводит к значительному ограничению набора управляющих элементов, пригодных для создания пользовательского интерфейса расширений комплексов. Последнее, в свою очередь, приводит либо к большим временным затратам на разработку расширений, либо к расширениям, реализованным не наилучшим образом.
Основным компонентом, обеспечивающим взаимодействие с управляющими элементами ActiveX, является контейнер управляющих элементов ActiveX.
Учитывая, что корпорация Microsoft не предоставляет инструментальных средств поддержки разработки ActiveX-контейнеров, а также малое количество публикаций, посвященных рассматриваемой тематике, можно говорить об актуальности проблемы создания технологии построения контейнеров управляющих элементов ActiveX.
Другой характерной особенностью создания промышленных программных систем, в частности, инструментального комплекса, ориентированного на разработку распределенных приложений, является наличие параллелизма и асинхронности вычислений. Как показывает практика,
и это подтверждается исследованиями [24], обнаружение в многопоточных Windows-приложениях ошибок, связанных с исключительными ситуациями -блокировками и зацикливаниями, является одним из наиболее трудоемких процессов.
Типичная проблема любых тупиков заключается в том, что они возникают асинхронно. Кроме того, существуют ситуации, которые похожи на тупики, но таковыми не являются. Например, поток может находиться в ожидании ресурса, требующего некоторое время для доступа. Следует также отметить, что большинство современных отладочных систем (debuggers) оказываются плохими помощниками для поиска ошибок такого рода.
Приведенные аргументы свидетельствуют о необходимости разработки формального метода анализа исходного кода Win32-nporpaMM с целью обнаружения в них ситуаций, приводящих к блокировкам.
Цель и задачи работы. Целью работы является создание современного инструментального комплекса для разработки и семантического анализа расширяемых распределенных приложений с графическим интерфейсом пользователя.
Для достижения указанной цели в диссертации поставлены и решены следующие задачи:
рассмотрены основные тенденции развития промышленных программных систем;
проведен анализ подсистем программирования, поставляемых в составе отечественных и зарубежных информационных систем;
проведены исследование и сравнительный анализ базирующихся на различных теоретических подходах методов обнаружения в программах исключительных ситуаций — блокировок и зацикливаний;
разработан формальный метод обнаружения блокировок в Win32-приложениях;
создана технология построения контейнеров управляющих элементов ActiveX;
на основе предложенной технологии выполнена практическая реализация ряда основных компонент инструментального комплекса разработки приложений RS-Forms.
Методы исследований, В диссертации используются методы семантической теории языков программирования, теории множеств, теории конечных автоматов, аппарат сетей Петри, методы объектно-ориентированного анализа, проектирования и программирования.
Научная новизна, В работе:
создана новая методика построения контейнеров управляющих элементов ActiveX, позволяющая упростить и значительно ускорить процесс их разработки;
предложена классификация контейнеров управляющих элементов ActiveX по предоставляемым функциональным возможностям;
предложен новый, базирующийся на семантической теории языков программирования, подход к анализу Win32 С-Н-программ с целью обнаружения в них ситуаций, приводящих к блокировкам;
показано, что семантическое значение Win32 С++-программы может быть представлено конечной системой рекурсивных уравнений;
показана применимость предложенного подхода для анализа программ, создаваемых под платформу Win32 на любом языке программирования.
Достоверность основных результатов подтверждается:
доказательством теоретических результатов и их апробацией на модельных примерах;
результатами внедрения работы в технологические процессы компании R-Style Softlab,
Практическая ценность. В работе;
создана технология построения контейнеров управляющих элементов ActiveX, позволяющая упростить и значительно ускорить процесс их разработки; основу технологии составляет библиотека С++-классов, функциональные возможности, расширяемость и гибкость которой позволяют использовать ее в промышленных программных проектах;
разработана программа автоматизации процесса создания (на основе предложенной технологии) ActiveX-контейнера посредством генерации исходного С++-кода, обеспечивающая быстрое построение остова контейнера и позволяющая на примерах познакомиться с предлагаемой технологией, испытать технологию в действии;
разработан семантический метод, позволяющий автоматизировать процесс анализа исходного кода \Уіп32-программ с целью обнаружения в них ситуаций, приводящих к блокировкам;
разработан набор базовых компонент для построения графического интерфейса пользователя, входящих в состав инструментального комплекса RS-Forms.
Реализация результатов работы. На основе разработанной технологии построения контейнеров управляющих элементов ActiveX в компании R-Style Softlab создан инструментальный комплекс разработки приложений RS-Forms.
Апробация работы. Основные результаты работы докладывались: на 8-ой международной научно-технической конференции "Радиоэлектроника, электротехника и энергетика" (г, Москва, 2002); на мелсдународных конференциях "Информационные средства и технологии" (г.Москва, 2001, 2002); на семинарах в Управлении программных разработок компании R-Style Softlab; на семинарах кафедры ПМ МЭИ (ТУ). Программный комплекс RS-Balance компании R-Style Softlab, созданный с использованием результатов работы, был представлен на 14-ой ежегодной российской выставке информационных технологий "СОФТУЛ'2003"-
Публикации. По теме диссертации опубликовано 7 работ.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы и четырех приложений. Общий объем основного текста включает 138 стр., в том числе 35 рис. и 2 таблицы. Список литературы состоит из 64 наименований.
В первой главе рассмотрены подсистемы программирования, поставляемые в составе отечественных и зарубежных прикладных программных комплексов- Проведен анализ сред создания графического интерфейса пользователя, встроенных в отечественные информационные системы. Обоснована необходимость разработки инструментальных средств поддержки построения ActiveX-контейнеров - основных компонентов, обеспечивающих возможность работы с управляющими элементами ActiveX. Рассмотрены проблемы реализации параллельных вычислений в программах, создаваемых для операционных систем семейства Microsoft Windows.
Во второй главе рассмотрены общие принципы создания контейнеров управляющих элементов ActiveX. Предложена технология построения ActiveX-контейнеров, целью разработки которой является предоставление эффективных механизмов для реализации:
контейнеров-форм — ActiveX-объектов, являющихся контейнерами для других ActiveX-объектов;
контейнеров-представлений - ActiveX-контейнеров, работать с которыми можно как с дочерними окнами Windows (child window);
s-контейнсров - не имеющих визуального представления контейнеров произвольных СОМ-объектов.
Фундаментом технологии является библиотека повторно используемых С++-классов, разработанная при помощи интегрированной среды Microsofl Visual C++ 6,0 и библиотеки ATL 3.0.
В основу построения библиотеки положен принцип открытости-закрытости, суть которого состоит в том, что модули, методы и классы должны
быть открыты для расширения, но закрыты для модификации. Гибкость и расширяемость библиотеки достигаются за счет применения при ее разработке шаблонов проектирования и шаблонов C++,
В главе подробно рассмотрено внутреннее устройство объектов, составляющих ActiveX-контейнер, их структура, поведение, механизмы взаимодействия. Особое внимание уделено вопросам повторного использования библиотеки. Рассмотрены различные подходы к ее использованию.
В завершении главы приводится описание реализованной утилиты, расширяющей функциональные возможности среды Microsoft Visual C++ до механизма генерации исходного кода остова контейнера с заданными характеристиками.
В третьей главе проведен сравнительный анализ базирующихся на различных теоретических подходах методов обнаружения в программах исключительных ситуаций - блокировок и зацикливаний. В основе первого метода лежит теория сетей Петри, в основе второго — алгебраическая семантика языков параллельного и распределенного программирования.
На основе результатов исследования указанных подходов разработан формальный метод поиска блокировок по исходному тексту программы, созданной для платформы Win32 — базовой платформы операционных систем семейства Microsoft Windows.
Идея метода состоит в моделировании Win32-пpилoжcния АФС-программой. При этом происходит абстрагирование от конкретной функциональности, реализуемой тем или иным №іп32-потоком, а основное внимание акцентируется на аспектах синхронизации.
Анализ полученной АФС-программы базируется на теории алгебраической семантики и на результатах применения этой теории к языку АФС, представленных в [17]. Для моделирующей АФС-программы строится семантическое значение. Это значение анализируется на предмет выявления
исключительных ситуаций. В случае обнаружения таковых, определяется приводящая к ним последовательность действий — в терминах элементов семантических областей. Далее происходит обратное преобразование к цепочке выполнения операторов АФС-программы, а от них - к последовательности вызовов функций Win32 API. Полученная последовательность позволяет выявить причины возникновения исключительной ситуации.
Работа метода подробно продемонстрирована на примере,
В четвертой главе рассмотрен разрабатываемый в компании R-Style Softlab на основе предложенной в настоящей работе технологии построения контейнеров управляющих элементов ActiveX инструментальный комплекс RS-Forms, предназначенный для создания расширяемых распределенных приложений с графическим интерфейсом пользователя.
Рассмотрена структура RS-Forms, архитектура создаваемых на его основе приложений, входящие в его состав средства разработки. Показаны ключевые отличия RS-Forms от существующих аналогов-
Особое внимание уделено компонентам, созданным на основе предложенной технологии: контейнеру — оконной оболочке для произвольного ActiveX-элемента, управляющим элементам "форма", "печатная страница" и "табулятор", s-контейнеру "меню".
Представлена концепция, лежащая в основе реализованных в RS-Forms средств быстрой разработки управляющих элементов ActiveX.
Механизмы взаимодействия приложений в операционных средах Microsoft Windows
Необходимая поддержка со стороны компании Microsoft, поставляющей рассматриваемые операционные системы, состояла в создании технологии OLE 1 (Object Linking and Embedding — Связывание и внедрение объектов) и затем более совершенной ее версии OLE 2.
Первая версия OLE для связи между приложениями использовала аппарат, называемый динамическим обменом данных (DDE — dynamic data exchange). Механизм DDE обладал рядом существенных недостатков, основными из которых были недостаточная надежность и гибкость- Решением этих проблем стало создание технологии COM (Component Object Model — модель многокомпонентных объектов) [34]. Технология СОМ определяет общую парадигму взаимодействия программ любых типов, СОМ быстрее, гибче и надежнее чем DDE [33, 34]. Вторая версия OLE была переписана с использованием СОМ.
Технология OLE представляет собой механизм создания и работы с составными документами и является воплощением документа-ориентированной модели работы с компьютером. С точки зрения пользователя» составной документ выглядит единым набором информации, но фактически он содержит элементы, созданные двумя или несколькими разными приложениями- С помощью этой технологии пользователь мог, например, объединить электронную таблицу, созданную Microsoft Excel, с текстовым документом Microsoft Word.
Посредством технологии СОМ одно приложение может стандартным образом предоставлять любые свои сервисы другому приложению. Этот стандартный способ обеспечения программируемости приложений называется автоматизацией.
Сегодня многие приложения, разрабатываемые как Microsoft, так и другими фирмами, обеспечивают доступ к своим сервисам посредством автоматизации. Благодаря этому становится возможным создавать программы-клиенты1, которые в полном смысле могут управлять данными приложениями извне. Например, Microsoft Excel поддерживает автоматизацию через объекты СОМ, чьи методы зеркально отражают действия, которые могут быть выполнены посредством пользовательского интерфейса Excel: вычисление формул по значениям нескольких ячеек электронной таблицы, корректировка орфографии и т.п.
Развитие системных технологий привело к существенным изменениям во встраиваемых макроязыках. Во-первых, в большинство из них были добавлены средства для доступа к сервисам, предоставляемым
Программа или компонент, использующие другой компонент, называются клиентом. программируемыми приложениями. Другими словами, макроязыки превратились из внутреннего инструмента в механизм взаимодействия приложений между собой, что позволило решать большинство задач, аналогичных рассмотренной в приведенном ранее примере.
Во-вторых, популяризация объектно-ориентированного подхода к разработке программ [27, 29], поддержка взаимодействия с программируемыми приложениями, сервисы которых предоставляются в виде методов и свойств соответствующих объектов, развитие RAD-систем (Rapid Application Development — быстрая разработка приложений), наметившаяся общая тенденция перехода к компонентному подходу создания программного обеспечения привели к поддержке (возможно, частичной) в этих языках объектно-ориентированной парадигмы. Языки стали предметно-ориентированными, более простыми в освоении и доступными пользователю "не программисту".
Так, в конце 1996 г. вышла новая версия пакета Microsoft Office, в которой были реализованы рассмотренные концепции. Во все приложения, входящие в Microsoft Office 97, была встроена единая среда разработки расширений, созданная на основе Microsoft Visual Basic [2] и получившая название Visual Basic for Applications (VBA) [3]. Таким образом, все приложения пакета имели единый язык разработки расширений, позволявший, в частности, работать с программируемыми приложениями, первыми представителями которых были опять же приложения Microsoft Office.
В следующем году компания R-Style Softlab выпустила объектно-ориентированную версию языка RSL — языка разработки расширений, встроенного в выпускаемые компанией программные комплексы [5,8]. Немного позднее в этот язык была добавлена поддержка объектов автоматизации.
Претерпели изменения и встроенные средства разработки интерфейса пользователя, поставляемые компанией Microsoft. В первую очередь это связано с популярностью среды быстрой разработки приложений Microsoft Visual Basic. Подход Visual Basic к построению графического пользовательского интерфейса базируется на вставке различных управляющих элементов в форму. Отличительной чертой Visual Basic, во многом определившей его успех, была поддержка компонентной технологии VBX (Visual Basic Extension). VBX - это технология создания программных компонентов, которые можно использовать в среде разработки Visual Basic наравне со стандартными (поставляемыми со средой). Элементы управления VBX получили большое распространение; третьими фирмами были предложены различные виды сервисов, построенных с использованием этой парадигмы программирования.
Создание более общего механизма взаимодействия программных компонентов на основе СОМ привело к определению общих стандартов и для управляющих элементов - разработке спецификации Microsoft ActiveX Controls [33], Эта спецификация определяет стандартный способ отображения компонентами собственного пользовательского интерфейса, стандартный механизм посылки событий своим клиентам, стандартный механизм, позволяющий клиенту читать и изменять значения свойств компонента и т.д. Учитывая, что компонентам необходим способ эффективного взаимодействия с использующим их программным кодом, спецификация определяет и правила создания контейнеров управляющих элементов - клиентских программ, "знающих" как работать с этими элементами.
Устройство объекта связи с управляющим элементом
Шаблонные классы CChiJdAx и CChildAxCreator (рис. 2.7) определяют стандартный механизм создания дочерних объектов. Общим элементов всех дочерних объектов является слабая ссылка (weak reference) [34] на родительский объект. Шаблон CChildAx определяет такую ссылку; ее тип задается параметром шаблона TAxCont. Также CChildAx реализует функции SetVoid и FinalConstruct, обеспечивающие корректную инициализацию этой ссылки. Использование указанных функций вместо конструктора класса связано с поддержкой принятой в ATL методики создания объектов.
Параметр TBase задает тип базового для CChildAx класса. По умолчанию используется ATL-класс CComObjectRootEx (рис. 2.7), предоставляющий реализацию интерфейса lUnknown и являющийся базовым для большинства классов, создаваемых на основе библиотеки ATL, Шаблон CChildAxCreator в единственной функции Createlnstance (рис. 2.8) инкапсулирует обобщенный алгоритм создания экземпляров классов, задаваемых через параметр Т. Этот алгоритм аналогичен стандартному для ATL алгоритму создания объектов, реализованному в классе CComObject [35], за тем исключением, что через дополнительный входной параметр pCont» он позволяет передавать вновь создаваемому объекту указатель на соответствующий ему контейнер. Рис, 2.8. Классы CChildAxCreator и CAxSiteCreator Упомянутый в разделе 2.2.1.4 шаблон CAxSiteCreator определяет интерфейс доступа к функции Createlnstance класса CChildAxCreator, накладывающий ограничения на типы как создаваемых объектов, так и их контейнеров. Более конкретно, в роли контейнера может выступать объект любого класса, производного от рассмотренного ранее CAxContBaselmpl, классом создаваемого объекта должен быть CAxSiteBase или класс, от него производный (выполнение этих требований проверяется на этапе компиляции), Класс CAxSiteBase инкапсулирует основные операции, выполняемые над управляющим элементом, а также реализует обязательные, в соответствии со спецификацией Microsoft ActiveX Controls, интерфейсы объекта связи. CAxSiteBase является наследником класса, инстанцированного по шаблону CChildAx с фактическими аргументами CAxContBaselmpl и CAxSiteLight (рис. 2.7). Таким образом, CAxContBaselmpl представляет собой базовый тип контейнера, с которым могут взаимодействовать экземпляры рассматриваемого класса. Класс CAxSiteLight, передаваемый в качестве второго параметра, определяет механизм именования объектов связи, а, следовательно, и сопоставленных с ними элементов управления1. Этот механизм обуславливает корректность алгоритмов, реализованных в классе CAxContLightlmpl , Кроме того, класс CAxSiteLight поддерживает метод доступа к интерфейсам ActiveX-объекта.
На диаграмме (рис- 2.7) показаны реализуемые классом CAxSiteBase стандартные интерфейсы объекта связи, включая диспетчерский интерфейс (ambient dispatch), предоставляющий управляющему элементу доступ к свойствам окружения контейнера. Необходимо отметить, что в некотором смысле CAxSiteBase является супер-иитерфейсом объекта связи и в ряде случаев требуется доступ к этому интерфейсу через механизм Querylnterface. Удовлетворение указанного требования осуществляется за счет поддержки в рассматриваемом классе специализированного интерфейса IAxSiteBase (рис, 2.9), Метод GetObject этого интерфейса возвращает указатель на CAxSiteBase. Доступ к IAxSiteBase через вызов функции Querylnterface обеспечивается стандартным для библиотеки ATL способом [36]. Класс CAxSiteBase реализует описанные в приложении 2 операции по созданию, инициализации, активизации и разрушению элемента управления. Кроме того, он определяет функции, позволяющие управлять положением, размером и видимостью ActiveX-объекта, подключаться к его событиям, сохранять значения его свойств и т.п.
Метод обнаружения исключительных ситуаций в №іп32-приложениях
Отличительной особенностью программного интерфейса Win32 является то, что он предоставляет полный контроль над ресурсами, которые могут быть причиной исключительных ситуаций [24, 39]. Все объекты синхронизации работают только локально, то есть, они влияют только на потоки, которые их используют.
Основная идея метода состоит в моделировании №іп32-приложения АФОпрограммой, При этом происходит абстрагирование от конкретной функциональности, реализуемой тем или иным \Уіп32-потоком, а основное внимание акцентируется на аспектах синхронизации. Моделирование синхронизирующих объектов и функций осуществляется с использованием операционного подхода к формальному заданию семантики на основе неформального описания, приведенного в [38,39] (см. ниже утверждение 1).
Анализ полученной таким образом программы базируется на теории алгебраической семантики и на результатах применения этой теории к языку АФС, представленных в [17]. Для моделирующей АФС-программы строится семантическое значение» представляющее собой, в данном случае, эквационально характеризуемое множество вычислительных последовательностей. Это значение анализируется на предмет выявления исключительных ситуаций. В случае обнаружения таковых, определяется приводящая к ним последовательность действий - в терминах элементов семантических областей. Далее, происходит обратное преобразование к цепочке выполнения операторов АФС-программы, а от них — к последовательности вызовов функций Win32 API. Полученная последовательность позволяет выявить причины возникновения исключительной ситуации.
Важно отметить, что для однозначного обратного перехода от последовательности действий в терминах семантических областей к операторам языка АФС необходимо обеспечить уникальность одноименных операторов функциональных процессов.
Все указанные шаги могут быть автоматизированы. Работа метода подробно продемонстрирована на примере в одном из следующих разделов.
Как было отмечено ранее, основу метода составляют теории операционной и алгебраической семантик языков программирования. Поскольку объектом исследования являются исключительные ситуации, то мы абстрагируемся от конкретной функциональности, реализуемой тем или иным приложением, и рассматриваем только вопросы межпоточного и межпроцессного взаимодействия.
Покажем возможность применения метода к программам, создаваемым на языке C++. Для этого зададим операционную семантику синхронизирующих функций Win32, предназначенных для реализации параллельных вычислений. В соответствии с [16], операционная семантика задается в терминах некоторой "абстрактной машины", а семантическое описание языка определяет трансляцию конструкций (функций) языка в коды этой машины. В данном случае, под "абстрактной машиной" будем понимать устройство, кодами которого являются инструкции языка АФС.
Предлагаемая Win32 модель взаимодействия параллельно выполняющихся потоков базируется на синхронизирующих объектах. Основными такими объектами являются: критические разделы, мьютексы, семафоры и события. Помимо них в процессе синхронизации могут участвовать: процессы, потоки, файлы, консольный ввод, уведомления об изменении файлов и т.п. [38]. Каждый из этих объектов может находиться в одном из двух состояний: свободном или занятом. Ключевое различие между ними — правила перехода из одного состояния в другое. Базовыми функциями, позволяющими потоку ожидать освобождения какого-либо объекта ядра, являются WaitForSingleObject и WaitForMultipleObjects. Специфика работы этих функций зависит от типа ожидаемого объекта. Все приведенные ранее объекты, за исключением критических разделов, представляют собой объекты ядра, более подробное их описание можно найти [38, 39].
Правила перехода объектов из одного состояния в другое можно разделить на две основные группы: определены специальные функции перевода объекта, как в свободное, так и в занятое состояние, либо, после успешного ожидания, объект в занятое состояние переводят Wait-функции, то есть присутствует, так называемый, побочный эффект успешного ожидания [39].
В общем случае, синхронизирующие объекты представляются в языке АФС одним или несколькими каналами (CHAN). Каждый канал может иметь один или несколько входов типа ALL и один или несколько выходов типа ALL. Объекту в свободном состоянии соответствует канал, готовый к выдаче данных, объекту в занятом состоянии - канал, готовый к приему данных. Функции ожидания моделируются с использованием оператора read, осуществляющим чтение из соответствующего выхода соответствующего канала [17].
Важно отметить, что с выходом новых операционных систем, появляются и новые типы объектов, способных участвовать в синхронизации потоков. Например, в Windows 2000 были добавлены объекты "задания" и объекты "ожидаемые таймеры" [39]. Однако это не меняет общей картины, так как методика работы с синхронизирующими объектами остается прежней.
Рассмотрим, каким образом основные функции, предназначенные для взаимодействия параллельно выполняющихся потоков, транслируются в коды языка АФС. Подробное неформальное описание этих функций приведено в [38, 39].
Компоненты RS-Forms, созданные на основе предложенной технологии построения ActiveX-контейнеров
В соответствии с предложенной во второй главе классификацией ActiveX-контейнеров, рассматриваемый контейнер представляет собой ориентированный на работу с единственным управляющим элементом контейнер-представление.
Функция создания объекта-контейнера, в числе прочих параметров, принимает идентификатор элемента управления, внедряемого в контейнер в процессе ее выполнения. Возвращаемый функцией результат - описатель окна контейнера (window handle), посредством которого дальнейшее взаимодействие (задание положения, размеров, управление видимостью и т.п.) с ним, равно как и с внедренным управляющим элементом, ведется стандартными методами, используемыми при работе с окнами Windows. В то же время, рассматриваемый контейнер поддерживает ряд специфических сообщений (посылаемых окну контейнера стандартной функцией SendMessage), среди которых, особого внимания заслуживает сообщение, позволяющее получить указатель на интерфейс IDispatch внедренного ActiveX-объекта. Через этот интерфейс приложение-клиент управляющего элемента обретает доступ к его основной функциональности.
В Дизайнере этот контейнер используется в качестве промежуточного звена для обеспечения работы с элементом управления "формой", элементом управления "печатная страница" и настраиваемыми элементами управления1. В аналогичной роли он используется и в подсистеме графического хоста2 на этапе выполнения.
В соответствии с предложенной во второй главе классификацией ActiveX-контейнеров, управляющий элемент "форма" является контейнером-формой. В RS-Forms этот элемент используется для создания экранных и печатных форм и реализует все, рассмотренные в разделах 4.3.4. Особенности экранных форм и 4.3.6. Компонентный подход, операции взаимодействия с ними. Более конкретно: он обеспечивает возможность работы с любыми управляющими элементами, зарегистрированными в реестре Windows; позволяет работать со стандартными управляющими элементами RS-Forms без их регистрации в реестре; реализует механизм процентной привязки координат внедренных элементов к границам формы; поддерживает динамическую вставку управляющих элементов на этапе выполнения, внедрение и включение по ссылке ранее созданных форм; предоставляет средства для формирования множества контекстных меню и их сопоставления внедренным элементам управления» поддерживает отображение контекстных меню на этапе выполнения; реализует операцию вывода своего представления на печать.
Кроме того» он обеспечивает взаимодействие со справочной подсистемой; предоставляет средства управления видимостью внедренных элементов управления, последовательностью их обхода клавиатурой; позволяет задавать гарнитуру и размер шрифта, используемого управляющими элементами по умолчанию, цвет фона, цвет текста и пр.; поддерживает работу с буфером обмена (clipboard) - в режиме редактирования любой внедренный элемент управления может быть скопирован в буфер обмена, а затем вставлен в туже или другую форму, при этом он сохранит все ранее установленные для него значения свойств.
Стоит особо отметить, что рассматриваемый элемент управления позволяет задавать расположение внедренных в него ActiveX-элементов в двух единицах измерения: в пикселях и в сотых долях миллиметра (himetric ах). Поддержка последней обеспечивает возможность создания форм, визуальное представление которых будет корректным при любом размере установленных в операционной системе шрифтов (small fonts, large fonts). Более того, спроектированные в сотых долях миллиметра формы сохраняют расположение своих элементов при выводе на печать. В том смысле, что на бумаге элементы формы будут иметь в миллиметрах в точности те размеры и положение, которые были заданы во время разработки.
В соответствии с предложенной во второй главе классификацией ActiveX-контейнеров, управляющий элемент "печатная страница" является контейнером-формой- В RS-Forms он используется для создания печатных страниц, рассмотренных в разделе 4.3.5. Механизм вывода информации на печать.
Этот управляющий элемент во многом похож на рассмотренный ранее управляющий элемент "форма". Как и "форма" он обеспечивает возможность работы с любыми управляющими элементами, зарегистрированными в реестре Windows; позволяет работать со стандартными управляющими элементами RS-Forms без их регистрации в реестре; поддерживает динамическую вставку управляющих элементов на этапе выполнения, внедрение и включение по ссылке ранее созданных форм.
Как и "форма" он позволяет задавать гарнитуру и размер шрифта, используемого управляющими элементами по умолчанию, цвет фона, цвет текста и пр.; поддерживает работу с несколькими единицами измерения и с буфером обмена.
Специфика управляющего элемента "печатная страница" состоит в интерпретации каждого внедренного в него ActiveX-объекта как абзаца, следствием чего является последовательное расположение элементов друг под другом. При этом предоставляются возможности задания вертикальных отступов, выравнивания по горизонтали, поддерживается работа с верхними и нижними колонтитулами, различными форматами бумаги и т.п.
В соответствии с предложенной во второй главе классификацией ActiveX-контейнеров, управляющий элемент "табулятор" является контейнером-формой. Однако, в отличие от выше рассмотренных управляющих элементов, он поддерживает работу только с элементом управления "форма", интерпретируемым, в данном случае, как страница свойств (рис. 4.2).
Подобное устройство позволяет в режиме редактирования располагать управляющие элементы на нужных страницах "табулятора" без использования слоев и без написания дополнительного кода, как это необходимо делать, к примеру, в системе "1С:Предприятие 7.7" [10, 11].
