Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

3.5. ПРОГРАММИРОВАНИЕ ОТ СОБЫТИЙ

135

§ 3.5. ПРОГРАММИРОВАНИЕ ОТ СОБЫТИЙ

Есть довольно обширный круг задач, которые естественно описывать как

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

граммы. Вообще говоря, так можно трактовать любую программу, обрабаты-

вающую данные: поступление очередного данного — это внешнее событие,

требующее реакции, которая, как минимум, должна быть связана с вводом

этого данного. Понятно, что такая трактовка далеко не всегда продуктивна.

Но она оправдана, например, когда есть много событий, порядок которых не

определяет логику обработки, когда реакция на каждое событие автономна,

т. е. не зависит от реакции на другие события. Общая характеристика по-

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

деляющими для целесообразного применения стиля программирования от

событий, или событийно-ориентированного стиля программирования:

• процессы генерации событий отделены от процессов их обработки;

• процессы отработки разных реакций не зависят друг от друга;

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

бытием и реакцией на него, никак не связанный с обработкой.

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

ности декомпозиции решаемой задачи, при которой генерация и обработка

рассматриваются объединенно. Например, в схеме программирования от со-

стояний вполне можно рассматривать в качестве событий появление данных,

приводящих к смене состояний. Однако здесь в каждом состоянии свои со-

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

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

зации вычислений. Область эффективного применения событийного стиля

программирования начинается именно там, где становится неудобным ис-

пользовать граф перехода между состояниями.

Стиль событийного программирования — это создание для каждого со-

бытия собственной процедуры-обработчика. Порядок, в котором обработчи-

ки описываются в программе, не имеет никакого значения. Более того, они

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

ным единицам программы, в рамках которых только и осмыслена реакция

на событие. Как следствие, продуктивно разбивать реакцию на событие на

части, за которые отвечают такие структурные единицы, и иметь несколько

реакций (разных) структурных единиц на одно событие.

136

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

Фактическую реакцию на событие, иными словами, вызов обработчика,

нужно связывать не со структурными единицами текста программы — с ни-

ми связаны программы обработчиков, а не их вызовы, а с теми динамически-

ми сущностями, которые порождаются при активизации этих структурных

единиц. По такой схеме организуются событийный механизм в рамках объ-

ектно-ориентированного программирования. Здесь обработчики, как и дру-

гие методы, приписаны к классам — структурным единицам текста програм-

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

осуществляют объекты, которые являются экземплярами классов, т. е. струк-

турными единицами процесса выполнения программы.

Когда имеется несколько реакций на одно и то же событие, встает вопрос

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

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

распределении объединенной реакции по программным компонентам. Прак-

тические потребности работы в таких ситуациях мотивируют особый стиль

программирования: программирование от приоритетов (см. следующий па-

раграф). В то же время выделяется важный с практической точки зрения

класс событийных программ с обособленными реакциями, который харак-

теризуется тем, что разные реакции на одно событие не конкурируют между

собой: каждая динамическая структурная единица (например, объект) дела-

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

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

ния контакта между событием и реакцией, теперь — реакциями! Суть его в

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

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

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

если для данного события должна быть выполнена реакция

то обработчик этой реакции вызывается для исполнения

// иначе в связи с событием данная структурная единица ничего не делает

Понятия,введенные при объяснении событийного программирования, ил-

люстрирует схема на рис. 3.5, на котором блоками с загнутыми углами изо-

бражены фрагменты текстов программ, а жирными стрелками — порожде-

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

обработчика может быть активизирована из разных динамических структур-

ных единиц, а также то, что одна и та же динамическая структурная едини-

ца может в разные моменты вычислений реагировать или не реагировать на

3.5. ПРОГРАММИРОВАНИЕ ОТ СОБЫТИЙ

137

S2S1

Изменение rE1 из O1 до повторной генерации E1:

O3(S2)O2(S1)O1(S1)

Описание структурных единиц, предусматривающих реакцию на соб ытия:

...

if(rE

)hE

;

if(rE

)hE

;

if(rE

)hE

;

...

if(rE

)hE

;

if(rE

)hE

;

...

Программы обработчиков событий

=true

= false

=true

=false

=true

Порождение динамических экземпляров структурных единиц

условия

активизации

реакций

, hE

(i =1, 2)

локальны в S2

условия

активизации

реакций

, hE

(i =1, 2, 3)

локальны в S1

Генерация событий и активизация реакций:

Генератор

событий

E1 ⇒ {O1.hE

, O2.hE

, O3.hE

}

E2 ⇒ {O1.hE

}

E3 ⇒ {O2.hE

, O3.hE

}

O1.rE1 := false;

Одна и та же программа из S1

Программа из S2

E1 ⇒ {O2.hE

, O3.hE

}

Рис. 3.5. Схема активизации обработчиков событий

138

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

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

работчик события, то в динамике вычислений он не может возникнуть ‘из

ничего’.

Примечательно, что цикл опроса может быть без труда распараллелен, и

разные структурные единицы, реагирующие на события, могут активизиро-

вать свои обработчики для совместного исполнения. Более существенно то,

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

зависящего от решаемой задачи цикла опроса. В таком случае от програм-

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

точиться на обработчиках, описываемых в контекстах структурных единиц

текста программы.

Когда составляемая программа целиком укладывается в схему событий-

но-ориентированного программирования с обособленными реакциями, а не

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

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

сающиеся обработки событий встраиваются (в разных смыслах: вызывают-

ся, подключаются как внешние библиотеки и др.) в стандартный программ-

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

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

задаче схемой, основанной на встраивании (см. рис. 3.6). Именно такая схема

событийно-ориентированного программирования приобрела сегодня широ-

кую популярность после того, как она была предложена в языке

Visual Basic

В замкнутом относительно средств объектно-ориентированного программи-

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

Think C++

Think

Pascal

Delphi

. Именно эту конкретную реализацию сегодня чаще всего на-

зывают событийно-ориентированным программированием. Как естественно

предположить, в этой объектно-ориентированной системе в качестве струк-

турных единиц программы, способных реагировать на события, выступа-

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

ниц — объекты. Обработчиками событий служат методы этих объектов.

До сих пор мы ничего не говорили о том, какие события возможны при

программировании в событийно-ориентированном стиле. Исторически этот

стиль как определенный “художественный прием” сформировался в области

разработки операционных систем, где естественно связывать понятие собы-

тия с прерываниями. Прерывание — это сигнал от одного из устройств (мо-

жет быть, и от самого процессора), который говорит о том, что произошло не-

что, на что нужно обратить внимание. Когда происходит прерывание, опера-

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

3.5. ПРОГРАММИРОВАНИЕ ОТ СОБЫТИЙ

139

Текст программы (основной), разрабатываемой программистом

Модули (библиотеки)

Встраивание,

вызов и т.д.

(любой смысл)

Библиотечные модули

Встраивание

(любой смысл)

Стандартизованный текст

программы (проект)

Фрагменты, разрабатываемые программистом

b) встраивание разрабатываемых модулей

a) составление последовательного текста программы

Рис. 3.6. Две схемы составления программы

событие как информационный объект, вызывающий реакцию программной

системы. Возможны разные способы реагирования на события, в том числе

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

никло прерывание, породившее это событие.

Из потребности такой обработки, собственно говоря, и сформировался

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

область его адекватного применения — реализация интерактивных взаимо-

действий программы с пользователем и решение других подобных задач (на-

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

логических процессов).

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

нажатия на клавишу, перемещения курсора мыши, указания световой кнопки

и т. п., не требуется. И не случайно именно те прерывания, которые способ-

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

тельской программы, стали основой для выработки систем событий, реакция

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

140

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

да можно передать от одного обработчика к другому, не нарушая условий

адекватного применения данного стиля: для этого достаточно объявить та-

кое перенаправление события как генерацию нового события. Но требуется

также генерация событий, не связанных с прерываниями.

К примеру,программируя в событийно-ориентированном стиле,естествен-

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

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

цесса никак не отражаются в системе прерываний, а потому обычные языко-

вые средства событийно-ориентированного программирования (например, в

Delphi

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

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

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

Об этом ограничивающем применимость подхода обстоятельстве пред-

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

беглом знакомстве с соответствующими средствами могут возникнуть ни на

чем не основанные ожидания с последующими разочарованиями и даже от-

торжением стиля, хорошо работающего на своем месте.

Примером языка, ориентированного на собственно событийно-ориенти-

рованное программирование, может служить

Perl

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

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

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

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

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

ствами или вообще отказаться от этого механизма в данной разработке.

В качестве иллюстрации этого тезиса ниже с позиций событийного сти-

ля программирования описываются “взаимоотношения” между синтаксиче-

ским анализом и вычислениями семантики программы. Реализация этих вза-

имоотношений — обычная задача, решаемая при разработке любого транс-

лятора. В событийном описании этой задачи в качестве событий системы

естественно рассматривать распознавание во входном потоке (транслируе-

мом тексте) синтаксических единиц, т. е. конструкций языка. Такое событие

требует в качестве обработчика семантическую подпрограмму, связанную

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

процесса: синтаксический анализ, задающий генерацию событий, и семан-

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

3.5. ПРОГРАММИРОВАНИЕ ОТ СОБЫТИЙ

141

мантических подпрограмм-реакций, упорядоченная событиями.

Коль ско-

ро есть концептуальное разделение процессов, его можно воплотить в реаль-

ной системе в событийном стиле. Это решение влечет за собой следующее:

• Необходимость рассмотрения в качестве событий не одного факта рас-

познавания конструкции, а двух: начало и завершение распознавания

конструкции, поскольку именно с ними, а не с конструкцией в целом

связываются семантические действия;

• Для обсуждаемой задачи существенно, что события возникают не в

произвольном порядке,их множество имеет вполне определенную струк-

туру. Нисколько не удивительно, что эта структура в точности соответ-

ствует синтаксической структуре текста:например,не может возникать

событие завершения распознавания конструкции раньше, чем возник-

нет событие начала конструкции;

• Следствием этой структуры является понятие ожидания вполне опре-

деленных, а не произвольных событий. Если ожидание не оправдалось,

то это можно считать событием еще одного вида: ошибочная ситуация.

Количество таких событий в точности равно числу наборов ожидаемых

событий.

При событийном программировании разделение процессов генерации и об-

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

граммирования транслирующих систем это качество считается не очень удоб-

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

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

синтаксический анализатор сам вызывает нужные семантические програм-

мы, когда распознает необходимость сделать это (в событийном стиле это

означает генерацию соответствующего события). Сопрограммную схему и

синтаксическое управление нам предстоит еще изучить в дальнейшем, здесь

же отметим только то, что нет никакого противоречия между двумя схемами,

и единственное различие между ними в том, что при синтаксическом упра-

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

вом подпрограммы. Иными словами,в схеме трансляции удается статически,

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

сов транслирующей системы: лексического анализа —генератора событий-лексем и синтак-

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

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

мой сопрограммного взаимодействия.

142

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

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

ет вызова их обработчиков (семантических подпрограмм). Вообще, сопро-

граммное взаимодействие можно трактовать как статически вычислен-

ную событийность

Разумеется, событийное программирование много шире случаев, в кото-

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

ботчики, т. е. когда полезно объединение генерации событий с их обработкой

и за счет такого объединения растворять события в программе. В частности,

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

интересны и такие случаи, когда объединение, хотя и возможно, но не дела-

ется. Конкретный пример —

XML/XSL

технология, для которой разделение

структуры и интерпретации текста считается принципиальным: это позво-

ляет строить ‘съемные’ системы обработки, иметь несколько независимых

таких систем для разного назначения. В своей сфере применения в такой

многовариантности усматриваются большие преимущества, но, как всегда,

перенос принципов данной технологии “куда угодно” чреват уже не раз от-

меченной неадекватностью.

§ 3.6. ПРОГРАММИРОВАНИЕ ОТ ПРИОРИТЕТОВ

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

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

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

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

ности является приписывание реакциям приоритетов: сначала выполняют-

ся те реакции, которые имеют больший приоритет. Этот прием, как выяви-

лось на практике, пригоден для решения достаточно широкого круга задач.

Он стал основой для формирования самостоятельного стиля программиро-

вания от приоритетов.

Этот стиль порожден практическими потребностями. Он предназначен

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

ски порождаемых и динамически исчезающих. Фундаментальных теорети-

Статическое вычисление некоторых частей программ — очень важный и имеющий в

потенциале исключительно широкую область применения прием программирования. Если

программист предусматривает, что его программа будет частично вычислена до основного

выполнения программы, то он следует еще одному стилю: специализирующему программи-

рованию, который рассматривается в § 3.9.3.

3.6. ПРОГРАММИРОВАНИЕ ОТ ПРИОРИТЕТОВ

143

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

В частности, в классической работе Хоара [76], в которой рассматривает-

ся управление взаимодействующими процессами, предполагается, что про-

грамма написана в традиционном структурном стиле, и никаких попыток

приспособить ее к обстановке, где есть много процессов, нет.

Стиль программирования от приоритетов не реализован систематически

в виде законченного языка (в качестве некоторой попытки можно привести

проект

Joule

, см. ???), но часто используется в прикладных языках скриптов

для управления процессами или событиями либо в распределенных систе-

мах, либо на полуаппаратном уровне (так называемые встроенные програм-

мы, являющиеся частью специализированного прибора или устройства).

В программировании от приоритетов, как и в сентенциальном програм-

мировании,порядок расположения операторов в программе имеет малое зна-

чение, зато имеет значение его приоритет, т. е. некоторое значение, принад-

лежащее в самом общем случае частично-упорядоченному множеству и по-

чти всегда рассматриваемое как элементарное. После завершения очередно-

го оператора среди оставшихся выбирается оператор с максимальным прио-

ритетом. Если таких операторов с равными или несравнимыми приоритета-

ми несколько, то, вообще говоря, в идеале надо было бы выбирать один из

них недетерминированно.

Об операторах, имеющих приоритеты, можно говорить, когда програм-

мирование от приоритетов реализовано в специально предназначенном для

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

приоритетов в обычном языке, то в качестве таких операторов могут высту-

пать иные структурные единицы текста программы. В объектно-ориентиро-

ванном языке, как правило, это методы объектов. Для краткости, в рамках

настоящего параграфа мы будем говорить об операторах, имея в виду только

что сделанное замечание.

При назначении приоритетов важно различать случаи,когда они задаются

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

ся для динамических структурных единиц, т. е. для тех элементов процесса

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

ны с тем или иным оператором, приоритет которого определяется в рамках

конкретного экземпляра (например, объекта). Таким образом выстраиваются

По этой причине область применения языка

OCCAM

. непосредственно реализующего

идеи Хоара, оказалась неоправданно суженной до тех ситуаций, когда процессы жестко при-

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

144

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

разные системы приоритетов, причем во втором случае система приоритетов

вынуждено оказывается динамической.

На практике обычно используют жесткую дисциплину, базирующуюся на

порядке операторов в программе. Часто управление по приоритетам соеди-

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

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

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

выжидает момент, когда можно будет начать исполняться). И текущий «нор-

мальный» процесс, и проснувшиеся демоны имеют свои приоритеты, и де-

мон начнет исполняться, даже если он активизирован, лишь в том случае,

если среди активных не осталось процесса с большим, чем у демона, прио-

ритетом. Эта схема реализована, в частности, в системе

UNIX

Уместно отметить, что событийно-ориентированное программирование

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

ный случай стиля программирования от приоритетов: для каждого экземпля-

ра структурной единицы, способной реагировать на события, выставляется

(бесконечно большой) приоритет, если этот экземпляр фактически должен

активизировать реакцию, и не выставляется приоритет (выставляется беско-

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

тие. Общий случай стиля событийно-ориентированного программирования

также близок к стилю программирования от приоритетов, если считать, что

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

явлении, присвоены приоритеты, соответствующие фактическому порядку

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

активизируемым обработчикам присвоены равные приоритеты.

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

граммированием от приоритетов состоит в принципах задания управления.

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

событием и реакцией: если условие срабатывания открывает для обработ-

чика возможность быть выполненным, то он обязательно будет выполнен в

ответ на соответствующее событие. При программировании от приоритетов

ситуация иная: задавая демону даже наивысший приоритет, можно лишь на-

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

появления какого бы то ни было события. Если абстрагироваться от меха-

низма управления при оперировании с приоритетами и событиями, то можно

считать эти два стиля вариантами одной сущности.

Стили программирования от событий и приоритетов хорошо совмеща-

ются, взаимно дополняя друг друга, когда целесообразна следующая архи-