CC BY
54
СОЗДАНИЕ АВТОМАТНЫХ ВЕБ-ПРИЛОЖЕНИЙ
С.А. Сытник
Научный руководитель - д.т.н., профессор В.Г. Парфенов
В статье приводится пример простого веб-приложения, в котором история переходов между вебстраницами является важной. Указываются недостатки традиционного подхода к его реализации, предлагается автоматный подход.
Введение
Веб-приложения, являясь поставщиками различных сервисов, богатыми источниками информации и удобными средствами коммуникации, прочно вошли в современную жизнь. С ними работают как на производительных рабочих станциях, так и на мобильных телефонах.
Создавая веб-приложение, разработчик пользуется большой свободой в выборе способа его реализации. Это имеет много положительных сторон. Однако, когда приложение становится достаточно объемным, с большим количеством переходов между страницами, возникают сложности различного характера. Одна из них - будем называть ее «проблема контекста» - играет большую роль в том случае, когда поведение приложения зависит от пути перемещения пользователя по веб-страницам - другими словами, когда важна история переходов.
Эта проблема может быть решена при применении традиционного подхода к разработке веб-приложения, однако мы покажем, что структура приложения при этом может быть довольно сложной.
В настоящей статье предлагается автоматный подход к разработке, основанный на SWITCH-технологии [1], разрешающий проблему контекста. Программы, написанные при помощи автоматного подхода, сосредотачивают логику в едином месте программы, хорошо читаемы и легко модифицируемы. Этим можно объяснить то обстоятельство, что автоматный подход становится все более популярным как при программировании в общем, так и при веб-программировании. Автоматный подход, например, описан при разработке javascript-компонентов в работе Э. Принга [2].
В направлении использования автоматного подхода к разработке веб-приложений было проведено некоторое исследование [3]. При этом для реализации веб-приложений использовалось программное средство UniMod [4], в основе которого также лежит SWITCH-технология.
1. Проблема контекста в веб-приложениях
Действия, совершаемые веб-сервером при обработке запроса, очевидно, зависят от того, какая веб-страница запрашивается и какие параметры запроса ему были переданы. В общем случае действия зависят также от состояния запрашиваемой страницы и от истории предшествующих переходов по другим страницам до попадания на данную страницу:
actions = f (request, page, state, history), где actions - совершаемые действия, f - некоторая зависимость, request - совокупность параметров запроса, page - текущая страница, за state мы обозначили ее состояние, а history - предшествующая история переходов по другим веб-страницам.
При программировании веб-приложения эту зависимость приходится учитывать. Будем называть это задачей учета контекста. При этом под контекстом условимся понимать совокупность четырех обозначенных сущностей (request, page, state и history), от которых зависят выполняемые при поступлении запроса действия:
actions = f (context),
context = (request, page, state, history).
Задача учета контекста может возникнуть в следующих трех случаях.
1) Переход на данную страницу возможен с некоторых других (двух или более) страниц, например, с целью ее повторного использования.
2) Возможен переход с некоторой страницы на ту же самую страницу, например, в результате возникшей ошибки ввода пользователя.
3) В зависимости от истории переходов до попадания на данную страницу требуется совершить некоторый переход (например, возврат на «вызывающую» страницу) и, возможно, некоторые различные действия.
В каждом из этих случаев веб-серверу может потребоваться совершить некоторые действия (рис. 1).
{^Веб-страница (^Веб-страница 2^)
Действие 1
Действие 2
<i
Данная веб-страница
Действие 1
f Данная веб- Л ^ страница J"
Действие 2
1) Переход на данную неб-С1раницу возможен с нескольких других веб-Сфаниц
2) Переход на данную вебстраницу возможен с этой же веб-страницы
Данная веб-страница
Действие 1
Действие 2
Веб-страница 1 } ( Веб-странииэ 2
3) С данной веб-страницы возможны переходы на разные веб-страницы
Рис. 1. Случаи возникновения задачи учета контекста
Проблема контекста заключается в том, что не существует метода программирования веб-приложений, описывающего, как можно удобно решить задачу учета контекста. Другими словами, неясно, каким образом можно учесть внутреннее состояние страницы и предшествующую историю посещения других страниц, чтобы совершить нужные действия. Вследствие этого задача контекста традиционно решается бессистемным введением различных «флагов». Например, если логика приложения должна «понять», с какой страницы совершен переход на данную страницу (случай 1, рис. 1), а потом использовать эту информацию для выбора перехода (случай 3, рис. 1), то программист должен предусмотреть для этого специальный «флаг», указывающий, с какой веб-страницы произошел переход.
2. Автоматный подход к реализации
Использование «флагов» совершенно не формализовано и может привести к многочисленным логическим ошибкам при проектировании приложения, в особенности при его усложнении. Попытаемся избавиться от них. Это представляется весьма актуальным, так как логика даже простых веб-приложений обычно не выглядит тривиальной.
Используя 8'1ТСН-технологию, мы можем представить веб-приложение в виде конечного автомата, где каждой странице соответствует одно состояние, имеющее внутри себя выходное воздействие - формирование и выдачу веб-страницы.
Событиями (е) будут являться ввод пользователем адреса в строке веб-браузера и нажатия им на ссылки и кнопки на веб-страницах. При запросе к веб-серверу также будут передаваться другие параметры, используемые при вычислении входных переменных (х) и выходных воздействий (г). Это автоматически позволит нам избавиться от «флагов», так как эту задачу возьмут на себя состояния и переходы между ними.
Для сохранения состояния автомата (у) воспользуемся возможностью хранить данные текущей сессии пользователя на сервере. Эта возможность поддерживается
всеми современными средами разработки, в том числе Java Servlets или PHP [5, 6]. Однако при необходимости (к примеру, если мы работаем на кластере из нескольких серверов, когда сессия недоступна), ее можно эмулировать самостоятельно через параметры запроса.
Структуру и направления обмена данными для автоматного подхода описывает следующая схема (рис. 2).
Рис. 2 Структурно-функциональная схема работы автоматного веб-приложения
Для того чтобы иметь возможность разрешать проблему контекста, мы можем воспользоваться следующими приемами:
1. разделить состояние автомата, соответствующее одной веб-странице, на несколько подсостояний; при этом изначальное состояние становится гиперсостоянием в общим выходным воздействием (вывод страницы);
2. явно выделить условия переходов, зависящих от контекста, в отдельные переходы между состояниями конечного автомата.
Проиллюстрируем применение автоматного подхода к разработке веб-приложения на простом примере.
3. Пример
Пусть требуется разработать веб-приложение, реализующее функциональность отправки SMS-сообщений. Для того чтобы отправить сообщение, пользователю необходимо указать номер телефона получателя и ввести текст сообщения. Также потребуем от пользователя указания email-адреса отправителя. Ввиду того, что этот email-адрес может изменяться достаточно редко, следует предусмотреть возможность его редактирования и запоминания для последующей подстановки «по умолчанию» в форму отправки сообщения. Для удобства пользователя следует предоставить эту возможность как независимо, так и в процессе отправки SMS-сообщения.
Диаграмма использования этого приложения имеет довольно простой вид (рис. 3). Следуя этой диаграмме, спроектируем приложение таким образом, чтобы оно состояло из трех веб-страниц, схематично представленных на рис. 4. Назначение этих страниц заключается в следующем.
1) «Главная страница» предоставляет пользователю возможность перейти либо к вводу email по умолчанию с последующим возвратом на главную страницу, либо к отправке SMS-сообщения.
2) Страница «настройки» отображает текущий «email по умолчанию» и разрешает его отредактировать.
3) При попадании на страницу «отправка SMS» текущий «email по умолчанию» автоматически подставляется в поле «email». Затем пользователь может изменить «email», ввести номер отправителя «to», текст сообщения «text» и отправить SMS. Также имеется возможность воспользоваться ссылкой «изменить email по умолчанию...». При этом пользователь попадет на страницу настроек, где он сможет, изменив email по умолчанию, вернуться к странице отправки SMS и продолжить редактирование (при этом «email» должен измениться на новое значение «email по умолчанию» автоматически).
Рис. 3. Диаграмма использования веб-приложения
Рис. 4. Схематичное представление веб-страниц приложения
На рис. 5 представлена схема связей автомата, а на рис. 6 - диаграмма переходов автомата. Код программы строится по диаграмме переходов формально и изоморфно.
Выделим достоинства и недостатки автоматного подхода.
Достоинства приведенного подхода:
1) Структура программного кода, построенного по диаграмме переходов, обладает достаточно хорошей читаемостью, отсутствием дублирования логики в разных местах программы; при этом добавление новых функций не требует большого изменения в коде программы, а реализация поддержке сложной условная логики имеет достаточно простой вид. Такой код хорошо поддается поддержке и модификации.
2) Отсутствие некоторых проблем, присущих реализации при помощи традиционного подхода, а именно:
a. отсутствие «флагов»;
b. все переходы явно указывают, с какой страницы на какую происходит переход и какие действия при этом совершаются. Это упрощает добавление новых страниц по сравнению с традиционным подходом;
с. логика, а, следовательно, и установка выходных данных, необходимых для формирования страницы, собрана в одном месте, что упрощает восприятие программы.
еО {пустое событие} АО z10 Вывод главной странииы
е20 Вывести араницу настроек z11 Переход на страницу настроек
е21 Сохранить email по умолчанию ¿12 Переход на страницу отправки SMS
е22 Отменить, ввод email по умолчанию z20 Вывод страницы настроек
еЗО Вывести страницу отправки SMS z21 Сохранение email ло умолчанию в уЗ
е31 Отправить SMS-сообщение z22 Ошибка при вводе email по умолч. в уЗ
е32 Отменить отправку SMS-сообщения ¿23 Сохранение email по умолчанию в у4
х20 Ошибка при вводе email по умолч.? z24 Ошибка лри вводе email по умолч. в у4
z25 Отмена ввода email по умолч.
хЗО Ошибка при вводе email? z30 Вывод страницы отправки SMS
х31 Ошибка при вводе получателя ? z31 Действия по успешной отправке SMS
¿32 Ошибка лри отправке (email)
z33 Ошибка при отправке (получатель)
z34 Вызов страницы настроек
z40 Вывод eiранииы ошибки
Рис. 5. Схема связей
3) Программа реализована в строгом соответствии со 8'1ТСН-технологией, а значит, к ней может быть применен весь построенный для нее аппарат, как существующий в настоящее время, так и, возможно, полученный в будущем. Этому способствовал тот факт, что мы избежали использования так называемого автомата с глубокой историей, для которого такой аппарат фактически отсутствует.
4) Предложенная 8'1ТСН-технологией нотация гиперсостояний нашла свое новое применение при описании веб-страниц. Одной веб-странице может соответствовать несколько состояний, но, если мы внесем их в общее для них гиперсостояние, соответствующее всей веб-странице, это облегчит понимание диаграммы переходов автомата. Это немаловажно, учитывая взаимнообратное соответствие диаграммы переходов и кода программы. Хотя гиперсостояние не имеет ни одного перехода, оно, тем не менее, выполняет не только функцию группировки состояний, но и содержит логически общие выходные воздействия. Таким общим воздействием является запрос на формирование веб-страницы.
Недостатки подхода:
1) Нет реентерабельности страниц. Хотя опыт показывает, что в веб-приложениях «вызов» веб-страниц используется ограниченно, а реентерабельность страниц требуется еще гораздо реже, тем не менее, это является недостатком. Вероятно, этот недостаток может быть разрешен при помощи конечного автомата со стековой памятью, однако рассмотрение этой возможности выходит за рамки настоящей статьи.
2) Для длинных последовательностей страниц, учитывающих историю предыдущих переходов, число дополнительных состояний для одной и той же страницы может достигать больших значений.
Рис. 6. Диаграмма переходов Заключение
В настоящей работе был предложен автоматный подход к их разработке, базирующийся на SWITCH-технологии. При этом была затронута проблема контекста. Было дано определение этой проблеме, показано, когда она возникает, каким образом разрешается, а также даны соответствующие комментарии.
Приведенный подход имеет достаточно сильные ограничения, среди которых: отсутствие поддержки реентерабельности веб-страниц, многооконности и асинхронных запросов (AJAX [7]), что требует проведения дальнейшего исследования в этом направлении. Не менее актуально исследование в направлении преобразования веб-приложений, реализованных с применением традиционного подхода, в автоматные веб-приложения, которое также проводится автором.
В заключение следует отметить, что автоматный подход к разработке веб-приложений, и, в частности, предложенный способ решения на базе него проблемы контекста, представляется достаточно удобным.
Литература
1. Шалыто А. SWITCH-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука. 1998. http://is.ifmo.ru
2. Pring E. Finite state machines in JavaScript, Part 1: Design a widget. http://www-128.ibm.com/developerworks/web/library/wa-finitemach1/
3. Методические рекомендации и указания по разработке, базирующиеся на принципах автоматного программирования, интернет-системы. http://is.ifmo.ru/science/ME-Internet.pdf
4. Гуров В., Мазин М. UniMod. Веб-сайт проекта UniMod. http://unimod.sourceforge.net/
5. Hunter J. Java Servlet Programming. O'Reilly, 1998
6. Веб-сайт проекта PHP. http://www.php.org
7. Технология AJAX. http://ru.wikipedia.org/wiki/AJAX
