Опубликован: 04.04.2012 | Доступ: свободный | Студентов: 1936 / 37 | Оценка: 4.60 / 4.40 | Длительность: 13:49:00
Лекция 8:

События

< Лекция 7 || Лекция 8: 123 || Лекция 9 >
Аннотация: В лекции рассматривается технология проектирования ПО, в которой процесс вычисления управляется событиями, возникающими по ходу процесса. Как правило, такая технология применяется в интерактивных системах, где ведущая роль управления процессом вычислений отводится пользователю. В такой технологии программный проект рассматривается как набор сервисов, вызываемых в ответ на возникновение событий, инициатором которых зачастую является пользователь, управляющий процессом вычислений. Центральным понятием этой технологии является понятие "события". Одни элементы ПО, называемые издателями, могут генерировать события. Другие элементы ПО, называемые подписчиками, могут обрабатывать события, получая сообщения об их возникновении. В лекции подробно рассматриваются важнейшие элементы этой технологии – объявление событий, включение событий, подписка на события, обработка событий, образец проектирования МОК (MVC).

Кто в ответе?

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

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

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

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

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

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

Программирование, управляемое событиями, применимо во многих различных областях. Оно с успехом применяется в графическом интерфейсе пользователя — GUI, что и станет нашим первым примером.

Управляемое событиями GUI-программирование

Старый добрый ввод:


Рис. 7.1.

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

from
  read_line
  count : = 0
until
  exhausted
loop
  count := count + 1
    — Сохранить last_line в позиции count в Result:
Result [count] := last_line
  read_line
end

Здесь read_line пытается читать следующую строку ввода, сохраняя ее в last_line, а значение exhausted принимает значение true, если при выполнении read_line нет больше строк для ввода.

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

Современный интерфейс

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

Рассмотрим приведенный далее снимок экрана. Он иллюстрирует стек переполнения, возникшего из-за бесконечной рекурсии при выполнении программы в EiffelStudio. Сам пример не имеет значения — все современные среды разработки, использующие GUI, похожи. Интерфейс пользователя включает элементы управления : текстовые поля, кнопки, меню, таблицы и другие.

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

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

 Интерфейс программы

увеличить изображение
Рис. 7.2. Интерфейс программы

Мы не знаем.

Конечно, мы могли бы использовать большой оператор if... then ... elseif... end или конструкцию выбора со многими ветвями, перечисляя все возможности:

inspect
  user_action
when "Нажата кнопка Stop" then
  "Завершить выполнение"
when "Введен текст в поле Class Name" then
"В соответствующее окно (слева вверху) вывести текст класса, имя которого
задано в текстовом поле"
when    …Другие ветви…
end

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

Проектирование, управляемое событиями ("издатели-подписчики"), предлагает в такой ситуации совсем другую схему.

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

 Включение и обработка событий

Рис. 7.3. Включение и обработка событий

Стиль "Издатели-подписчики" полезен в различных областях приложения: GUI-программирование — это просто один из примеров. Другие примеры:

  • сети передачи данных, где возможна широковещательная передача, — один передатчик и много приемников;
  • управление процессом. Сюда входят программные системы, управляющие производственными процессами. В таких системах данные поступают от многочисленных датчиков, следящих за температурой, давлением и другими характеристиками процесса. Возникающие в результате события обрабатываются подготовленными элементами ПО.
< Лекция 7 || Лекция 8: 123 || Лекция 9 >
Надежда Александрова
Надежда Александрова

Уточните пожалуйста, какие документы для этого необходимо предоставить с моей стороны. Курс "Объектно-ориентированное программирование и программная инженения".