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

Сначала 70-х годов появилась новенькая архитектура многозадачных систем, достаточно резко отличающаяся от вышеперечисленной модели поочередных процессов. Идет речь о так именуемых системах, управляемых событиями (event-driven systems). На 1-ый взор, концепция систем, управляемых событиями, близко родственна гармонически взаимодействующим процессам. Различие меж этими архитектурами состоит, быстрее, во взоре на то Системы, управляемые событиями, что представляет собой программка. В модели гармонически взаимодействующих потоков процесс выполнения программного комплекса представляет собой совокупа взаимодействующих нитей управления. В системе, управляемой событиями, программка представляет собой совокупа объектов, обменивающихся сообщениями о событиях, также реагирующих на сообщения, приходящие из наружных источников. В эталоне, объекты ведут взаимодействие меж собой только через сообщения. Приходящие Системы, управляемые событиями сообщения побуждают объект поменять свое состояние и, может быть, породить некое количество сообщений, созданных для других объектов. При таковой модели взаимодействия нам непринципиально, исполняются ли способы объектов как параллельные (либо псевдопараллельные) нити, либо же поочередно вызываются единой нитью, менеджером либо диспетчером сообщений.

В первый раз эта архитектура была реализована в Системы, управляемые событиями экспериментальных настольных компьютерах Alto, разработанных в 1973 году в исследовательском центре PARC конторы Xerox. Целью опыта было создание операционной среды, комфортной для сотворения интерактивных программ с оживленным пользовательским интерфейсом. В этих системах в первый раз была реализована многооконная графика, когда юзер сразу лицезреет на дисплее графический вывод Системы, управляемые событиями нескольких программ и может активизировать всякую из их, указав на соответственное окно с помощью манипулятора-“мыши”.

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

Каждое сообщение о событии представляет собой структуру данных, которая содержит код, обозначающий тип действия: движение мыши, нажатие кнопки и т Системы, управляемые событиями. д., также поля, разные для разных типов событий. Для "мышиных" событий – это текущие координаты мыши и битовая маска, обозначающая состояние кнопок (нажата/отпущена). Для клавиатурных событий – это код нажатой кнопки, обычно, ASCII-код знака для алфавитно-цифровых и особые коды для стрелок и других “расширенных” и “многофункциональных” кнопок – и Системы, управляемые событиями битовая маска, обозначающая состояние разных модификаторов, таких как SHIFT, CNTRL, ALT и т. д. Для зрительных событий – это координаты прямоугольника, который необходимо перерисовать, и т. д.

Все сообщения о событиях помещаются в очередь в порядке их появления.

В системе существует понятие обработчика событий. Обработчик событий представляет собой объект, т. е. структуру Системы, управляемые событиями данных, с которой связано несколько подпрограмм-методов. Один из способов вызывается при поступлении сообщения. Обычно он также именуется обработчиком событий. Некие системы предлагают объектам-обработчикам предоставлять разные способы для обработки разных событий, к примеру, способ onclick будет вызываться, когда придет событие, сигнализирующее о том, что кнопка мыши была нажата Системы, управляемые событиями и отпущена, когда курсор находился над областью, занимаемой объектом на дисплее.

Разглядим объект графического интерфейса, к примеру меню. При нажатии на кнопку мыши в области этого меню вызывается обработчик действия. Он разбирается, какой из пт меню был избран, и отправляет соответственное командное сообщение объекту, с которым ассоциировано меню Системы, управляемые событиями. Этот объект, в свою очередь, может отправить командные сообщения каким-то другим объектам. К примеру, если была выбрана команда File/Open, меню передаст обработчику основного окна приложения сообщение FILEOPEN, а тот, в свою очередь, может передать команду Open объекту, отвечающему за прорисовку и обработку файлового диалога.

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

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

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

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

Высочайшая динамичность интерфейса проще всего обеспечивается, если каждый обработчик стремительно заканчивается. Если же в силу природы запрашиваемой операции она не может закончиться стремительно – к примеру, если мы воткнули знак, параграф удлинился на строчку, и в итоге текстовому микропроцессору типа WYSIWYG (как мы лицезреем, так и получаем Системы, управляемые событиями) приходится переформатировать и переразбивать на странички весь следующий текст – мы можем столкнуться с неувязкой. В таковой ситуации (а при написании реальных приложений она появляется сплошь и рядом) мы и обязаны задуматься о том, что все-таки в реальности представляют собою обработчики – процедуры, синхронно вызываемые единственной нитью менеджера событий, либо параллельно Системы, управляемые событиями исполняющиеся нити. 1-ая стратегия именуется синхронной обработкой сообщений, а 2-ая, соответственно, асинхронной. Графические интерфейсы первого поколения – Mac OS, Win 16 – реализовывали синхронную обработку сообщений, а когда обработчик думал навечно, отрисовывали неотъемлемый атрибут этих систем – курсор мыши в форме песочных часов. Несколько более совершенную архитектуру предлагает оконная подсистема Системы, управляемые событиями OS/2, Presentation Manager. PM также реализует синхронную стратегию обработки сообщений (менеджер событий всегда ожидает окончания еще одного обработчика), но в системе, кроме менеджера событий, могут существовать и другие нити. Если обработка действия просит долгих вычислений либо других действий (к примеру, воззвания к наружным устройствам либо к сети), рекомендуется сделать для этого отдельную Системы, управляемые событиями нить и продолжить обработку асинхронно. Если же приложение этого не сделает (к примеру, обработчик действия просто зациклится либо уснет на семафоре – это целочисленная переменная, через которую управляется вычислением нити: вычислять либо поставить в очередь), системная очередь сообщений будет заблокирована и ни одно из графических приложений не сумеет Системы, управляемые событиями работать. Современные версии РМ предоставляют в данном случае возможность отцепить “ненормальное” приложение от очереди либо даже принудительно окончить его. Асинхронные очереди сообщений предоставляют Win32 и оконная система X Window. Вобщем, и при асинхронной очереди занимающийся продолжительными размышления однопоточный обработчик событий – тоже малоприятное зрелище, ведь он не может перерисовать собственное окно Системы, управляемые событиями, потому передвижение других окон по экрану порождает любознательные эффекты. Разработчикам приложений для нареченных систем также рекомендуется выносить долгие вычисления в отдельные нити.

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


situacionnaya-zadacha-45.html
situacionnaya-zadacha-68.html
situacionnaya-zadacha-9.html