Geum.ru

Ордена ленина институт прикладной математики им. М. В. Келдыша Российской Академии Наук

Вид материалаДокументы
2.Обоснование выбора схемы взаимодействия компонент
Подобный материал:
1   2   3   4   5   6

2.Обоснование выбора схемы взаимодействия компонент



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

Хотя особенности, отмечаемые при реализации насыщенных Веб-интерфейсов не типичны для современных средств поддержки разработки, в недавнем прошлом можно найти программные средства с аналогичными свойствами. Прежде всего имеется ввиду широко известная архитектура пользовательского интерфейса, названная Model-View-Controller (MVC) в той своей первоначальной инкарнации, когда она появилась в языке Smalltalk-80 [11] [12].

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

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

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

В общих словах, свойства динамически конфигурируемой архитектуры пользовательского интерфейса обеспечиваются за счет накладываемого в триаде MVC требования отсутствия прямых зависимостей модельного слоя по отношению к слоям управления и презентации. Это требование, в свою очередь, приводит к необходимости реализации потока синхронизации изменений между модельным и презентационным слоями, обращенном в обратном направлении по отношению к основному потоку управления (так называемая pull-синхронизация). Последнее предполагает, что разработчику должны быть доступны программные механизмы, необходимые для реализации pull-синхронизации – известные также как средства квази-непрерывного, статусного взаимодействия (если пользоваться терминологией из области статусно-событийного анализа, представленной в работах [13] [14]).

В роли базового программного средства для pull-взаимодействия между компонентами MVC в Smalltalk было предложено использовать механизм Наблюдателя (Observer-Observable, Publish-Subscribe), который однако, как показал опыт практического использования, оказался инструментом, доступным только для системных программистов высокого уровня квалификации (собственно, на этот уровень рассчитывалась тогда MVC). В частности, одной из наиболее неприятных проблем, характерных для подобных процедурных механизмов pull-синхронизации, является отсутствие встроенного механизма, позволяющего предотвратить зацикливание программы.

Отмеченные возможности архитектуры MVC, заложенные в Smalltalk, нашли свое развитие в еще одной известной реализации – Java Swing [15], где все стандартные элементы форм в пользовательском интерфейсе (кнопки, поля ввода, меню, таблицы и т.п.) построены по принципам MVC с использованием механизма Наблюдателя [16]. За счет этого в Swing обеспечивается уникальная возможность настройки внешнего вида стандартных компонент пользовательского интерфейса, который может в процессе работы приложения динамически подстраиваться под образ элементов из различных операционных систем (pluggable look-and-feel) путем простой замены объектов в слое, отвечающем за визуализацию элементов. С другой стороны показательно, что в Swing для компоновки прикладных форм – т.е. решения задач, относящихся к компетенции прикладного, а не системного программиста - схема MVC и механизм Наблюдателя не используются. Здесь применяются обычные для современных систем разработки пользовательского интерфейса подходы: обработка событий, прямое манипулирование атрибутами объектов и пр..

Идея адаптировать парадигму взаимодействия компонент в MVC к задачам построения клиентской архитектуры Веб-приложений с насыщенным пользовательским интерфейсом кажется очень перспективной. Особенно интересными и важными с практической точки зрения представляются такие фундаментальные свойства синхронизации по схеме MVC, как опосредованность (mediated interaction) и статусность (statefulness).

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

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