Кейно П.П.
ФГБОУ ВПО «Московский авиационный институт (национальный исследовательский университет)», г. Москва, преподаватель кафедры «Системное моделирование и инженерная графика»,
science @blockset.m
ПРЕДПОСЫЛКИ ФОРМИРОВАНИЯ НОВОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ВЕБ-УЗЛОВ BLOCKSET И ДЕКЛАРАТИВНОГО ЯЗЫКА BML
КЛЮЧЕВЫЕ СЛОВА
Веб-разработка, веб-приложение, программирование, серверное программирование, серверы, интерпретатор, декларативное программирование, визуальный редактор, BML, BlockSet, CGI, FastCGI, XML.
АННОТАЦИЯ
Представленная работа посвящена поиску эффективного метода решения задач, связанных с веб-разработкой. Затрагиваются аспекты разработки как клиентской, так и серверной стороны. Предоставляется теоретическая реализация разработанной методологии в виде модели, а также практической — в виде программного модуля интерпретатора и визуального редактора.
Относительно молодая сфера веб-разработки за свою недолгую историю обросла огромным количеством различных технологий и инструментариев. Как и в любых других отраслях, связанных с информационными технологиями в целом и программированием в частности, в веб-разработке важнейшим фактором является эффективность. Существует множество характеристик, определяющих данный фактор [1]. В представленной работе речь идёт о разработке эффективной методологии, позволяющей упростить решение ряда тривиальных задач, не затрагивая, при этом, гибкость.
Теоретическая реализация методологии включает в себя задачи перераспределения уровней абстракции, а также выявление основных сущностей, с которыми происходит работа. Практическая реализация представляет собой два самостоятельных проекта, связанных между собой понятиями методологии. Первый проект является интерпретатором декларативного языка BML (англ. BlockSet Modeling Language) [2], являющегося основной составляющей. Цель второго проекта заключается в наглядном представлении специфичных сущностей языка BML и интеграцией с классическими клиентскими технологиями [3].
Эффективный инструментарий строится по принципу оптимального распределения уровней абстракции: подчёркивания основных высокоуровневых сущностей и вынесении рутинных задач в базовые обобщённые алгоритмы. С повышением уровня абстракции упрощается процесс разработки, однако снижается гибкость. Зачастую, инструментарий с высоким уровнем абстракции не может предоставить достаточный функционал для реализации специфических свойств разрабатываемого объекта. И наоборот, низкий уровень абстракции заставляет разработчика тратить время на освоение инструментария и постоянному возвращению к рутинным задачам вместо сосредоточения сил на поиске основного решения [4].
Представленная работа посвящена серверной стороне веб-разработки. Говоря о серверной стороне, можно привести в пример различные технологии, начиная от фундаментальных интерфейсов связи внешней программы и веб-сервера (CGI, FastCGI) [5], заканчивая интерпретируемыми языками программирования, наилучшим образом решающих задачи динамической веб-разработки. К таким языкам относятся: Perl, PHP, Ruby, Python и др. Каждый из них оброс большим количеством дополнительных библиотек (фреймворков), облегчающих выполнение рутинных задач. На каждом из языков разработаны специализированные системы управления контентом (CMS, англ. Content Management System). Все упомянутые технологии работают на разных уровнях абстракции, имеют широкую целевую группу потребителей, начиная от новичков и заканчивая профессионалами индустрии. Каждый инструментарий имеет свои особенности:
Языки программирования: • низкий уровень абстракции, повышенная гибкость разработки, появление большого
количества рутинных задач;
• требуются профессиональные знания в области составления алгоритмов и написания программного кода;
• Фреймворки:
• средний уровень абстракции, оптимальное отношение эффективность/гибкость, рутина снижена до минимума;
• помимо профессиональных знаний, требуются дополнительные временные ресурсы на изучение специфики каждой из библиотек;
• Системы управления контентом:
• высокий уровень абстракции, знания в области программирования требуются либо на базовом уровне, либо не требуются вовсе;
• абсолютно не гибкая разработка, решаются только самые тривиальные задачи.
На клиентской же части технологии заточены на решение специфичных задач, которые не требуют реализации сложных алгоритмических структур, а вся немногочисленная логика, нерешаемая этими технологиями, решается одним единственным языком программирования клиентской стороны - JavaScript, интерпретируемым браузером.
Совсем по-другому обстоят дела на серверной стороне, где исполняется основная логика работы приложения, происходит обработка больших объёмов данных, их выборка из внешних хранилищ, вспомогательные вычисления и многое другое. Этим и обуславливается технологическое многообразие серверной стороны. Условно, все классические серверные технологии разработки можно разделить на четыре группы, расположив их в определённой иерархической последовательности (рис. 1). Похожая модель была предложена Эндрю Таненбаумом для наглядного представления зависимости между скоростью и объёмом по отношению к различным типам компьютерной памяти [6].
По мере продвижения с вершины иерархической пирамиды к её основанию, изменяются две основные характеристики. Во-первых, повышается гибкость разработки, что означает возможность реализации функционала любой сложности, в том числе и специфичного, разработка которого на более высоких уровнях затруднительна, либо невозможна в принципе.
Во-вторых, увеличивается время, затрачиваемое на разработку. Это следствие повышенной гибкости: на низких уровнях работа происходит с абстрактными сущностями, составляющих в комплексе сущности более высокого уровня с конкретно заданной спецификой. Таким образом, на нижних уровнях высокоуровневый функционал приходится составлять из элементарных частей.
Задачи, решаемые на серверной части, требующие детального анализа и поиска эффективного решения, сводятся к следующим группам:
• манипуляция данными (выборка, создание, обновление, удаление) [7];
Z
Рис.1. Иерархическая модель инструментариев веб-разработки
• валидация данных [8];
• авторизация и разграничение прав доступа пользователей [9];
• сопоставление запрошенного адреса URI и динамической страницы.
Становится понятно, что разрабатываемая методология должна обладать высоким уровнем гибкости, низким порогом вхождения, высокой скоростью разработки. Разумеется, заявленные приоритеты могут противоречить друг другу, поэтому основной задачей ставится поиск необходимого оптимума между ними.
Целью работы является разработка эффективного решения в сфере серверных веб-технологий и определение его места в представленной выше иерархии. Разрабатываемая методология построена по принципу постепенной доработки и модификации базовых сущностей, придании им дополнительных свойств, атрибутов. Основными сущностями методологии являются: модель, локация, набор, блок. По названиям наиболее значимых сущностей, методология получила название BlockSet (блок и набор) [10]. В BlockSet модель описывает основную структуру проекта. Локация представляет собой динамическую страницу и описывает её поведение. Набор является непосредственной составляющей модели и локации, содержит коллекцию данных различного типа. Блок - часть набора, ячейка данных определённого типа. У всех сущностей (кроме модели) имеется большое число модификаторов - атрибутов, которые задают определённую логику работы.
Важным свойством методологии является её самодостаточность: оперируя лишь описанными выше сущностями, становится возможной реализация проекта начального уровня. Однако, грамотное оперирование атрибутами-модификаторами даёт возможность реализовать и узко-специализированный функционал. Так наглядно демонстрируется принцип «от простого к сложному».
Язык BML (англ. BlockSet Modeling Language), упомянутый выше, синтаксически идентичен языку XML и основан на парадигме декларативного программирования. Декларативное программирование является одной из самых простых практик ведения разработки. Оно описывает не методику создания объекта, а его состояние в зависимости от внешних условий. Декларативный стиль программирования по уровню абстракции находится выше классического императивного, следовательно, освоение языка не будет представлять значительных трудностей для начинающего разработчика. Например, язык HTML, по своей природе являющийся декларативным, описывает общие свойства документа, а не то, как этот документ должен отображаться на экране. В работе предлагается применить данный подход на серверной стороне, описывая основную логику работы сущности в виде её свойств, а не абстрактных алгоритмов.
Опишем более детально основные сущности методологии. С помощью модели (элемент Model) определяется структура данных, и устанавливаются отношения объектов проекта между собой. Структурой данных проекта BlockSet является набор, содержащий в себе блоки и другие, вложенные наборы. Все наборы, используемые в проекте, необходимо описать в модели. Единственным дочерним элементом модели является набор, в то время как блок является единственным дочерним элементом набора. Именно в модели для всех блоков устанавливается тип данных.
Локация или расположение (элемент Location) представляет собой динамическую страницу, описывающую индивидуальную логику работы. У локации, как и у модели, прямыми потомками могут быть только наборы. Большинство атрибутов у наборов и блоков, присутствующих в модели, может быть переопределено в локации, либо определено вновь. Существуют также атрибуты, характерные только для локации. То есть локация задаёт уточняющие свойства обработки тех или иных данных. Исходя из этого, можно утверждать, что локации в парадигме MVC соответствуют контроллерам.
Локация идентифицируется шаблоном адреса. Шаблон адреса представляет собой часть URI, идентифицирующую путь, и содержащую динамические вставки, на место которых подставляются данные определённого типа, фигурирующие в генерации динамической страницы. Шаблон адреса динамической страницы задаётся атрибутом base (базовый адрес).
Набор (элемент Set) является коллекцией данных различного типа. Набор идентифицируется уникальным именем, с помощью которого набор может быть определён в модели и локации. Имя задаётся с помощью атрибута name. В контексте модели набор определяет структуру данных отдельно взятой коллекции и её отношение с другими наборами. Результатом выборки из набора является один или множество экземпляров набора. Выборка из набора осуществляется при обработке соответствующей локации, в которой задействован этот набор.
Блок (элемент Block) является непосредственной частью набора и представляет собой определённый тип данных. Тип данных может быть как элементарным, так и представлять собой сложную структуру, в том числе осуществляющей функции файловой обработки. В методологии BlockSet блок при любых обстоятельствах является элементарным типом данных, то есть обладает свойством атомарности [11]. Предварительное объявление блока у соответствующего набора в модели также является обязательным, как и объявление самого набора.
Условно, набор представляет собой таблицу в базе данных, а блок - поле в этой таблице. Отличие в том, что блок может обрабатывать сложные данные, оставаясь при этом элементарной сущностью в контексте методологии BlockSet. В некоторых случаях блок может брать на себя обработку сложных типов и структур, которые не ограничиваются лишь одним полем, а также работать с файлами. Кроме того, блок выполняет функцию валидации данных. Именно внутри блока происходит проверка на соответствие входных данных своему типу. Блоку каждого типа может соответствовать разный набор атрибутов. Это особенность методологии.
Оперируя понятиями методологии, разберём пример гипотетического проекта, логическая структура которого описывается на языке BML (листинг 1). Отметим, что для наглядности в листинге отсутствует упоминание блоков, задающих права доступа (о них упоминалось в [12]).
Листинг 1. Модель гипотетического проекта «диссертационные советы»
<model>
<set name="specialty">
<block name="cipher" type="string" /> <block name="name" type="string" /> <set name="council" relation="multi">
<block name="org" type="string" /> <block name="cipher" type="string" /> <set name="thesis" relation="parent">
<block name="subject" type="string" /> <block name="author" type="string" /> <block name="supervisor" type="string" /> <block name="pubdate" type="datetime" /> <set name="related_docs" relation="multi">
<block name="pubdate" type="datetime" /> <block name="name" type="string" /> <block name="attachment" type="file"
ext="pdf doc rtf odt" />
</set>
</set>
</set>
</set>
</model>
Гипотетический проект представляет собой базу диссертационных советов, проводящих защиту диссертаций по различным специальностям. Как можно видеть на структуре модели, проект содержит четыре набора: specialty (научная специальность), council (диссертационный совет), thesis (диссертация), related_docs (сопутствующие документы). Диссертационных советов может быть несколько, как и специальностей, по которым принимается защита. Поэтому у дочернего к "specialty" набора "council" установлен атрибут "relation" со значением "multi", что означает связь «многие ко многим» между наборами, если оперировать понятиями баз данных. Аналогичный атрибут установлен у набора "thesis" и набора "relation_docs" т.к. диссертационный совет может принимать защиту множества диссертаций, а каждая диссертация может содержать множество сопутствующих документов. У каждого блока есть свой тип, а у каждого типа может быть свой набор атрибутов, задающих, в том числе, и правила валидации данных. Например, блок "attachment", являющийся частью набора сопутствующих документов и представляющий собой вложенный файл, принимает только документы в формате PDF, DOC, RTF и ODT. Данные, сохраняемые в блоках других типов, также могут валидироваться, согласно правилам, установленным в атрибутах этих блоков.
Листинг 2. Пример локации
<location base="/diss/[council:cipher]/" template="list.tpl">
<set name="specialty">
<block name="cipher" /> <block name="name" /> <set name="council">
<block name="org" /> <block name="cipher" /> <set name="thesis" limit="20"> <block name="subject" /> <block name="author" /> <block name="supervisor" /> <block name="pubdate" condition=">01.01.2014"/>
<set name="related_docs">
<block name="pubdate" /> <block name="name" /> <block name="attachment"/>
</set>
</set>
</set>
</set> </location>
Локация, как уже было сказано выше, представляет собой одну из динамических страниц проекта. В локации необходимо продублировать все наборы и блоки, участвующие в выборке данных. В примере (листинг 2) представлена динамическая страница, отображающая список диссертаций определённого совета. Значение в атрибуте "base", заключённое в квадратные скобки, ([councilxipher]) обозначает, что на этом месте в строке адреса ожидается строка, идентифицирующая шифр диссертационного совета, и эта строка будет задействована при выборке данных. Все выбранные данные будут переданы в шаблонизатор, а в качестве шаблона будет задействован файл list.tpl (атрибут "template"). Кроме того, диссертации не должны быть старше даты 1 января 2014 года (атрибут "condition" у блока "pubdate"). Также выборка из набора "council" ограничена количеством 20 экземпляров (атрибут "limit').
Проведём аналогию использования парадигм программирования со строительством загородного дома. Непосредственное участие субъекта в постройке дома: укладка кирпича, установка окон и дверей, монтирование коммуникаций - всё это похоже на императивное программирование, т.к. дом строится на изначально пустом месте, а использование готовых компонентов (стройматериалов, окон и дверей, электрооборудования, сантехники) очень похоже на использование заранее подготовленных библиотек, коих существует огромное количество.
Стоит также добавить, что низкоуровневое программирование напоминает аналогичный процесс с оговоркой на то, что все готовые компоненты приходиться изготавливать самостоятельно из сырья: выжигать кирпич, вытачивать брус, выплавлять металлические изделия. Несмотря на свою сложность, достоинством этого процесса является то, что на выходе получаются именно те компоненты, какими они задумывались архитекторами и декораторами дома, в то время как заранее заготовленные компоненты не всегда соответствуют изначальной задумке проекта, а изменить их вид уже невозможно.
Декларативное программирование же напоминает работу архитектора, когда тот не задумывается подробно о том, как именно будет строиться та или иная часть дома, однако он чётко знает, какой вид должно принять определённое помещение, где и сколько должно быть установлено окон и дверей, как должен выглядеть фасад дома и многое другое. По макету, разработанному архитектором, производится непосредственное строительство. Этот процесс аналогичен интерпретации программы. Разработка эффективного и производительного интерпретатора является одной из задач работы.
На рисунке 2 представлена расширенная иерархическая модель в объёмном виде, на которой показано место методологии BlockSet и языка BML в сфере веб-разработки. Нижние два уровня остаются такими же, как в упомянутой ранее модели. Верхние три уровня левой стороны пирамиды являются непосредственными частями BlockSet и занимают смежные позиции с существующими технологиями. Так, на представленной схеме язык BML находится на уровне фреймворков, однако фреймворком не является, т.к. фреймворк подразумевает набор библиотек уже существующего языка программирования. Тем не менее, по характеристикам, которые
описывает предыдущая модель - скорость разработки и гибкость - предметно-ориентированный язык BML закономерно располагается именно на этом уровне.
Рис. 2. Место методологии BlockSet и языка BML в сфере веб-разработки
Свойства
Имя council
Ограничение 20 ¿J
Г Скрывать имя набора в строке адреса
Имя блока Порядок Тип
Г subject DESC • string •
Г author None • string •
Г supervisor None string i
Г pubdate None 1 datetirne
ДоОавить новый Удалить
Рис. 3. Окно создания нового набора
Методология BlockSet следует парадигме MVC или Model-View-Controller (модель-представление-контроллер) [13]. Уровни модели и контроллера строятся в языке BML, а роль представления берёт на себя шаблонизатор, получающий сгенерированные данные и накладывающий их на определённый шаблон. Шаблон представляет собой страницу на языке HTML с простейшими алгоритмическими структурами и специальными вставками, на место
которых будут подставлены данные в процессе генерации документа. Работа интерпретатора делится на два этапа: непосредственная интерпретация структур BML и передача выходных данных шаблонизатору. Именно по этой причине шаблоны и язык BML расположены на одном уровне.
Уровнем выше, наряду с системами управления контентом, расположен специализированный визуальный редактор, позволяющий наглядным образом, с помощью компонентов пользовательского интерфейса, строить конструкции языка BML (рис. 3), а также корректные шаблоны HTML, задавать стили CSS, составлять интерактивные алгоритмы JavaScript. По сути, визуальный редактор генерирует шаблоны для серверной стороны, а также целиком отвечает за разработку клиентской части. Часть функций по разработке клиентской части выполняют и системы управления контентом [14], как правило, имеющие в своём арсенале простейший визуальный редактор HTML/CSS.
Стоит оговориться, что визуальный редактор BlockSet не предназначен для управления содержимым. Он лишь предоставляет эргономичный интерфейс, в котором сочетается необходимый функционал для генерации динамических структур BML и работой с клиентской частью. Правильно построенный проект сам берёт на себя роль системы управления контентом и в целом представляет собой динамический веб-ресурс с возможностью разграничения прав доступа к своему содержимому. Именно поэтому законченный проект находится на самой вершине и также делит место на этом уровне наравне с системами управления контентом.
Описанная методология представляет собой новое средство веб-разработки, ориентированное как на начинающих веб-разработчиков, так и профессионалов индустрии. Главной особенностью является декларативная разработка, когда разработчик оперирует ограниченным набором сущностей, но может максимально изменить поведение, добавляя новые свойства каждой сущности. Взятый за основу язык XML предполагает минимизацию синтаксических ошибок, в силу своей распространённости, а визуальный редактор помогает ускорить процесс освоения новой методологии благодаря наглядности.
Литература
1. Ahmed A. et al. Agile software development: Impact on productivity and quality // Management of Innovation and Technology (ICMIT), 2010 IEEE International Conference on. - IEEE, 2010. - С. 287-291.
2. Кейно П.П., Силуянов А.В. Разработка и внедрение интерпретатора декларативного языка моделирования Web-интерфейсов на высоконагруженных системах // Прикладная информатика. 2015. № 1. С. 5-20.
3. Кейно П. П. Визуальный редактор BlockSet. Свидетельство о государственной регистрации программы для ЭВМ 2014662832, Dec 10, 2014.
4. Brodie M. L., Mylopoulos J., Schmidt J. W. (ed.). On conceptual modelling: Perspectives from artificial intelligence, databases, and programming languages. - Springer Science & Business Media, 2012.
5. Apte V., Hansen T., Reeser P. Performance comparison of dynamic web platforms / / Computer Communications. - 2003. -Т. 26. - №. 8. - С. 888-898.
6. Tanenbaum A. S. Structured computer organization. - Pearson, 2006.
7. Battle R., Benson E. Bridging the semantic Web and Web 2.0 with representational state transfer (REST) //Web Semantics: Science, Services and Agents on the World Wide Web. - 2008. - Т. 6. - №. 1. - С. 61-69.
8. Groenewegen D. M., Visser E. Integration of data validation and user interface concerns in a DSL for web applications //Software & Systems Modeling. - 2013. - Т. 12. - №. 1. - С. 35-52.
9. Sun H. M., Chen Y. H., Lin Y. H. oPass: A user authentication protocol resistant to password stealing and password reuse attacks // Information Forensics and Security, IEEE Transactions on. - 2012. - Т. 7. - №. 2. - С. 651-663.
10. Кейно П.П., Силуянов А.В. Автоматизированная разработка динамических Web-узлов средствами декларативного языка программирования // Прикладная информатика. 2015. № 1. С. 55-70.
11. Bhiri S., Perrin O., Godart C. Ensuring required failure atomicity of composite web services // Proceedings of the 14th international conference on World Wide Web. - ACM, 2005. - С. 138-147.
12. Кейно П.П. Унификация типов прав доступа к информационным ресурсам облачных Web-сервисов // Материалы XXII всероссийской научно-практической конференции «Проблемы информационной безопасности в системе высшей школы», Безопасность информационных технологий, НИЯУ-«МИФИ». 2015
13. Deacon J. Model-view-controller (mvc) architecture // [Online][Citado em: 10 de marfo de 2006.] http://www.jdl.co.uk/briefings/MVC.pdf. - 2009.
14. Bascones P., Carreras C. Managing memory institutions portals: from HTML to CMS and towards applications in XML for multi-platforms //International Journal of Digital Culture and Electronic Tourism. - 2008. - Т. 1. - №. 1. - С. 18-36.