Содержание к диссертации
Введение
ГЛАВА 1. Анализ методов разработки веб-приложений. 11
1.1. Веб-разработка, как итерационный процесс 11
1.2. Фокус-фактор командной разработки 12
1.3. Оптимизация процесса разработки 16
1.4. Существующие регламентирующие стандарты 19
1.5. Критерии качества 21
1.6. Параметры оптимизации 23
1.7. Формальное описание веб-приложения 25
1.8. Существующие методы веб-разработки 27
1.8.1. Препроцессинг и шаблонные технологии 27
1.8.2. Использование внешнего обработчика 28
1.8.3. Использование сервлетов 29
1.9. Существующие модели архитектур веб-приложений 30
1.9.1. Формализация синтеза контроллеров 35
1.9.2. Методы разработки контроллеров 37
1.9.3. Методы разработки уровня вида (представления) 41
1.9.4. Методы разработки уровня модели 42
1.10. Общий алгоритм разработки веб-приложения 45
1.11. Выводы 45
ГЛАВА 2. Разработка теоретических методов проектирования и создания веб-приложения 47
2.1. Методы разработки веб-приложений. Модель архитектуры 47
2.2. Жизненный цикл модели архитектуры веб-приложений 52
2.3. Методы разработки и анализа К-уровня 53
2.3.1. Ресурсный метод разработки 53
2.3.2. Метод графического анализа веб-приложения 55
2.3.3. Метод модульного анализа 58
2.3.4. Жизненный цикл элементов К-уровня и модулей 60
2.4. Методы разработки М-уровня 61
2.4.1. Формализация задачи модельной трансформации 62
2.4.2. Средства и методы объектно-реляционной проекции 63
2.4.3. Формальное описание типов схем отношений 67
2.4.4. Преобразование типов данных 70
2.4.5. Формальное описание объекта «Активная модель» 71
2.4.6. Формальное описание АМ-коллекции 74
2.4.7. Формальное описание итератора АМ-коллекции 74
2.4.8. Объектные запросы 75
2.4.9. Проекция связей отношений 77
2.4.10. Структура системы «Активная модель» 79
2.4.11. Реляционно-объектные преобразования 81
2.4.12. Объектно-реляционные преобразования 81
2.5. Выводы 82
ГЛАВА 3. Практические методики разработки веб-приложений 83
3.1. Организация загрузки веб-приложения 83
3.2. Методика работы со сторонними библиотеками 84
3.3. Безопасность веб-приложений 86
3.3. Методика интернационализации веб-приложений 92
3.3.1. Интернационализация данных 92
3.3.2. Интернационализация интерфейса 95
3.4. Методика организации кэширования 96
3.5. Организация жизненного цикла объектов системы 100
3.6. Методика аутентификации пользователя «брокер-провайдер».. 101
3.7. Интеграция со сторонними веб-приложениями 103
3.8. Выводы 104
ГЛАВА 4. Применение методов разработки веб- приложений 106
4.1. Информационная модель «торговая площадка» 106
4.1.1. Комплекс требований к веб-приложению 106
4.1.2. Отражение объектов предметной области 109
4.1.3. Структура модуля разрабатываемой системы 109
4.1.4. Базовый модуль веб-приложения 112
4.1.5. Взаимодействие с пользователями 116
4.1.6. Модели предметной области 117
4.1.7. Характеристика разработанной системы 118
4.2. Информационная модель «конструктор сайтов» 119
4.3. Информационная система «интернет-магазин» 123
4.5. Информационная модель публикации контента 126
4.6. Исследование предлагаемых подходов 126
4.6.1. Метрический анализ 127
4.6.2. Экономия трудозатрат 131
4.6.3. Измерение качественных характеристик 131
4.6.4. Измерение общих характеристик быстродействия 133
4.6.5. Изменение характеристик быстродействия системы объектно-реляционного преобразования 135
4.7. Выводы 138
Заключение 140
Список используемой литературы 143
Список условных сокращений 139
- Существующие модели архитектур веб-приложений
- Формальное описание объекта «Активная модель»
- Методика аутентификации пользователя «брокер-провайдер»..
- Изменение характеристик быстродействия системы объектно-реляционного преобразования
Введение к работе
д.т.н., доцент Сидоренко Валентина Геннадьевна
Актуальность темы: В последнее время в связи со стремительным развитием информационных систем и сетей пакетной коммутации возрастает роль информационных технологий в жизни общества, информатизации и создания глобального информационного пространства (сети Интернет). На данный момент сеть Интернет представляет собой совокупность веб-приложений (ВП). ВП – это клиент-серверное приложение, в котором клиентом выступает браузер (программное средство (ПС) для просмотра веб-сайтов) или другое ВП, а обслуживающим сервером – веб-сервер. В апреле 2012 года количество доменных имён индивидуальных пользователей и компаний по данным аналитической компании Netcraft составляет уже 676 919 707.
Самой распространённой платформой для разработки ВП на данный момент является LAMP – комплекс технологий в составе: операционной системы (ОС) Linux; веб-сервера Apache; реляционной базы данных (БД) MySQL и языка программирования (ЯП) PHP. PHP, входящий в состав платформы, обладает низким порогом вхождения (легкостью первоначального освоения), что также увеличивает распространённость платформы, однако именно это является причиной создания программного кода, не удовлетворяющего требованиям качества (согласно ISO 9126/ГОСТ 28195). Вместе с тем на данной платформе разрабатываются многокомпонентные программные решения с участием многих десятков разработчиков. ВП начинают оперировать огромными объемами данных, в том числе и персональными данными (такими как номера кредитных карт), что предъявляет высокие требования к программному коду (п.1.3 стандарта ISO 19759:2005/SWEEBOK). ВП развиваются чрезвычайно быстрыми темпами. В то же время, большая длительность разработки, согласования и утверждения международных и национальных стандартов приводит к их консерватизму, а также к хроническому отставанию требований и рекомендаций этих документов от современной практики и технологии создания сложных систем. Проблемам, связанным с созданием методов разработки ПС, их унификации и стандартизации, были посвящены работы В. В. Липаева, И. Катца, М. Фаулера, Э. Таненбаума, М. Стеена, Л. Торвальдса, Э. Д. Брауде, А.К.Кэя, В.Н. Агафонова, Г. Буча, Э. Йордана, Н.П. Бусленко, Е.Ф. Кодда, Б. Страуструпа, В. Ройса и многих других. Однако они не в полной мере учитывают специфику разработки на платформе LAMP с использованием свободных интернет-технологий. В этих условиях создание методов разработки ВП является актуальной задачей.
Целью данной диссертации является повышение эффективности методов и алгоритмов разработки, взаимодействия и хранения веб-приложений. Для достижения поставленной цели необходимо решить следующие задачи:
-
Формулирование критериев качества веб-приложений, и проведение критического анализа существующих методов разработки, хранения и взаимодействия веб-приложений.
-
Постановка и решение задачи оптимизации процесса разработки веб-приложений.
-
Синтез эффективной архитектуры и алгоритмов функционирования веб-приложений. Определение уровней абстракции в ВП, их взаимодействия и жизненного цикла.
-
Разработка метода взаимного объектно-реляционного преобразования (ОРП) для организации взаимодействия ВП с БД и хранения данных, а также шаблона проектирования на его основе.
-
Решения практических задач разработки ВП на базе предлагаемых методов, в том числе методов взаимодействия ВП друг с другом и пользователями. Определение конкретных путей повышения эффективности разработки, хранения и взаимодействия веб-приложений. Реализация новой архитектуры, алгоритмов функционирования и ОРП-метода в конкретном веб-приложении.
Объектом исследований являются веб-приложения на платформе LAMP.
Предметом исследований являются методы разработки ВП.
Методы исследований. Результаты диссертационной работы получены на основе теории множеств, теории реляционных баз данных, имитационного моделирования, экспериментальных и теоретических методов информационных технологий.
Научная новизна:
-
Проведён критический анализ существующих методов разработки, хранения и взаимодействия веб-приложений.
-
С помощью применения СКР-функции (среднестатистические колебания работоспособности) к определению дневного фокус-фактора (КПД) разработчика автор вычислил значение фокус-фактора (FFD) для новых команд, равное 0.72640625. Это значение может использоваться при планировании итерации новой команды, или индивидуальном планировании для нового члена команды разработки. Автором поставлена и решена оптимизационная задача по определению такого распределения задач по программистам, которое приведёт к максимизации показателя производительности (P разр) всей команды.
-
Разработаны новая архитектура и алгоритмы функционирования ВП. Определены уровни абстракции ВП и их жизненный цикл. Метрический анализ разработанного ВП показал, что значение целевой функции метрик на 13% превосходит максимальное значение этой функции для других ВП. Применение предлагаемых методов позволяет увеличить количество повторно используемого кода на 16%. Как следствие, могут быть сокращены объем работ, бюджет, а также увеличена скорость разработки ВП. Качественные характеристики ВП (по ISO/IEC 9126) по данным экспертного анализа увеличиваются на 19% по сравнению с максимальным значением среди других ВП.
-
Создан новый метод объектно-реляционного преобразования «Активная модель», позволяющий взаимно преобразовывать объекты ЯП PHP в таблицы сервера баз данных. По результатам проведённых тестов можно заключить, что скорость работы на тестовой выборке увеличилась на 19 - 27% для объектовозвращающего преобразования и на 16 - 25% для векторовозвращающего преобразования. Объем занимаемой памяти сократился на 16 - 24% для объектовозвращающего преобразования, и на 18 - 32% для векторовозвращающего преобразования по сравнению с системой Doctrine.
-
Разработаны методы решения практических задач синтеза ВП: методы загрузки ВП, методика работы со сторонними библиотеками, метод разграничения доступа к ВП, интернационализации данных и интерфейса, методика организации кэширования, методика аутентификации пользователя и взаимодействия со сторонними ВП. В результате тестирования было определено, что применение предлагаемых методов позволяет увеличить скорость обработки запросов ВП от 7% (при l = 15 и 35) до 35% (при l = 5).
-
Предлагаемая архитектура, алгоритмы функционирования ВП и ОРП-метод реализованы при создании нескольких ВП: системы публикации контента в сфере образования, визуального конструктора сайтов, системы управления сайтом, а также ВП, реализующего информационные процессы и структуры модели взаимодействия потребителя и производителя товаров и услуг (модель customer-supplier).
Практическая значимость. Сформулирован комплекс рекомендаций по разработке ВП, а также практических методик, позволяющих рационализировать информационную структуру ВП, его внутренних и внешних информационных процессов для унификации программного кода и улучшения качественных показателей (ISO 9126/ГОСТ 28195-89), а именно понятности, изучаемости, изменяемости и удобства для анализа.
Достоверность основных научных положений, выводов и рекомендаций, сформулированных в диссертации, обусловлена корректностью постановок задач, обоснованностью принятых допущений, удовлетворительной сходимостью результатов тестирования с данными, полученными в реальных условиях эксплуатации.
Апробация работы. Основные результаты диссертации докладывались и обсуждались на ежегодных научных конференциях МИИТа (Неделя науки «Наука МИИТа – транспорту» в 2008, 2010, 2011 гг.); на 12-м национальном форуме информационной безопасности «Информационная безопасность России в условиях глобального информационного общества» (2010 г.); на 7-й международной научно-практической конференции «Ключевые вопросы в современной науке» (2011г.); 8-й международной научно-практической конференции «Стратегические вопросы мировой науки» (2012г.); научно-технических семинарах и заседаниях кафедры «Вычислительные системы и сети» МИИТа в 2009-2011гг., а также на научных семинарах кафедры «МО АСУ» МИИТа в 2011г.
Реализация результатов работы. Методика разработки ВП и система ОРП использованы при реализации ВП - системы публикации контента в сфере образования в «Научно исследовательском институте инновационных стратегий развития общего образования» (НИИ ИСРОО), ВП, моделирующего информационные процессы и структуры модели взаимодействия потребителя и производителя товаров и услуг в ООО «Рубэй», а также при подготовке курсов «Информатика» и «Компьютерная графика» кафедры ВСС МИИТа. Результаты внедрения подтверждены соответствующими актами.
Публикации. По теме диссертации опубликованы 9 работ, из них 4 работы – в ведущих изданиях из перечня, определенного ВАК России для опубликования основных результатов диссертаций.
Структура и объем диссертационной работы. Диссертация состоит из введения, списка условных сокращений, четырех глав, заключения, списка цитируемой литературы (82 источника). Работа изложена на 152 страницах машинописного текста, включая 64 рисунка, 15 таблиц и 142 формулы, 5 приложений на 7 страницах.
Основные научные положения, выносимые на защиту:
-
Оптимизация процесса разработки веб-приложений.
-
Архитектура и алгоритмы функционирования ВП. Модель уровней абстракции в ВП, алгоритмы их взаимодействия и жизненный цикл.
-
Метод взаимного ОРП «Активная модель» для организации взаимодействия ВП с БД и шаблон проектирования на его основе.
-
Методы решения практических задач разработки ВП, в том числе методик взаимодействия ВП друг с другом и пользователями. Реализация предлагаемой архитектуры, алгоритмов функционирования и ОРП-метода в конкретных ВП.
Существующие модели архитектур веб-приложений
Направление создания ВП развивается чрезвычайно быстро. В течение последних 6 лет появились новые языки программирования (Ruby, Dart, Go), разметки (HTML5, SASS, SCSS, Наші), новые платформы (Ruby on Rails, Hivex, PhpFog) и технологии (облачные хранилища и вычисления, новые нереляционные базы данных). Вместе с развитием клиентских частей (веб-браузеров) развиваются и серверные. Платформы разработки делятся на проприетарные и свободные. К первым относятся: Microsoft .NET Framework (языки ASP, ASP.NET, C++); Java Enterprise Edition (Java), которая также поставляется в варианте с открытым исходным кодом; Hivext (доступный в виде веб-сервиса) и др. Также активно развиваются платформы с открытым исходным кодом: LAMP (PHP), Ruby on Rails (Ruby)[\6], Mono, Zope (Plone), Django (Python).
Препроцессинг - это операция обработки данных (программного кода), состоящая в подготовке их для другой программы[17]. В случае с ВП на вход препроцессора подается код на языке разметки HTML, в который внедрены директивы препроцессора (например, на языке РНР в случае РНР-препроцессора[18]). На выходе формируются данные в препроцессированной форме, где вместо директив для препроцессора включается результат их обработки. Язык РНР из платформы LAMP изначально создавался именно как язык препроцессинга[19], что отражено в его названии (расшифровывается как Php Hypertext Preprocessor). Препроцессинг представлен языками PHP, Perl, Python.
Шаблонные технологии являются аналогом препроцессинга. В них присутствует шаблон (на языке HTML) и метки в нём (специальные теги). Кроме того, есть программный код, находящийся вне шаблона (в отличие от метода препроцессинга), называющийся обработчиком шаблона. Таким образом, в шаблонных технологиях уровень представления, именуемый в них шаблонами, отделяется от всего остального кода ВП. Шаблонный подход также может быть представлен вышеназванными языками, а также языком Java и подходом Java Server Pages (JSP). Шаблоны программного кода используются также при сборочном подходе к разработке [20]. Основным преимуществом шаблонных технологий является отделение программного кода представления от всего остального ВП. Основным недостатком является то, что весь остальной код ВП не регламентирован в рамках модели, что составляет трудности при разработке комплексных ВП с большим количеством сущностей предметной области. Также при использовании шаблонных технологий без отделения логики от представления ухудшаются такие показатели качества ПС как С1 («структурность») и С4 («повторяемость»).
Препроцессинговые и шаблонные технологии активно развивались, что впоследствии привело к формированию систем управления контентом (CMS) [21], фреймворкам веб-разработки (CMF) и другим подходам.
Веб-сервер, принимающий запросы пользователя, может быть настроен так, чтобы осуществлять их передачу (проксирование) на определённую внешнюю программу через специализированные интерфейсы (CGI, FastCGI и др.). В этом случае внешним обработчиком будет являться ВП. Такой подход является одним из первых методов разработки ВП. Первым ВП был скрипт на языке Perl, подключаемый через CGT-интерфейс. Недостатком данного подхода является фокусирование разработчика на интерфейсе между ВП и веб-сервером и отсутствие рекомендаций и стандартов построения самого ВП внутри обработчика, как следствие происходит смешение интерфейса, реализации, функциональности и представления внутри ВП. Это приводит к постановке дополнительных задач, снижению производительности работы программиста и ухудшению таких показателей качества, как С2 («простота конструкции») и С4 («повторяемость»). Далее будет дано определение ВП такого типа. Пользуясь подходом внешнего обработчика, трудно разрабатывать комплексные ВП, однако такой подход применяется до сих пор. На данный момент такой подход вытесняется методом демонизации скриптов, при котором программа-обработчик сама принимает входное воздействие на определённый порт компьютера-сервера и генерирует ответ. В качестве примера можно привести программы-демоны на языках PHP(phpDaemon), Ruby(EventMachine), Python(Twisted) и Javascript (Node.JS).
Платформа Java Enterprise Edition (JEE/J2EE) использует модель многоуровневого распределенного приложения. Логически приложение разделено на компоненты в соответствии с их функциональностью[22]. Различные компоненты, составляющие !/2.Е -приложение, установлены на различных компьютерах в зависимости от их уровня в многоуровневой среде ЛЕЕ, которой данный компонент принадлежит. Хотя ./ЗЕЕ-приложение состоит из трех или четырех уровней, многоуровневые /ІЕ Е -приложения обычно принято называть трехуровневыми, так как они расположены на трех различных системах: клиентский компьютер, сервер J2EE и сервер базы данных или обычный сервер. Технология J2EE использует сервлеты, которые были разработаны как альтернатива CGI и работает по принципам, схожим с использованием внешнего обработчика. Сервлет является внешним обработчиком, вызываемым по специальному интерфейсу. Сервлеты при выполнении находятся в одном адресном пространстве, что позволяет увеличить производительность с помощью сокращения времени, требуемого на загрузку и инициализацию. Однако в сервлетах очень часто смешиваются функциональный уровень и уровень отображения, и они не решают проблем структурного синтеза ВП. Это приводит к ухудшению таких показателей качества ПС, как С1 («структурность») и С2 («простота конструкции»).
Структурный синтез ВП основан на определённой классификации исходного (или скомпилированного) кода ВП. В настоящий момент принято несколько классификаций исходного кода. В соответствии с клиент-серверной природой ВП всё множество файлов программного кода делится на клиентские файлы и серверные. В состав клиентских файлов входят JavaScript-6n6jinoTQKH, изображения, файлы таблиц стилей (CSS), отвечающих за отображение интерфейса. В состав серверного множества файлов входят библиотеки языка РНР (для платформы LAMP); файлы конфигураций; файлы тестирования, т.е. тот код, который исполняется на сервере. В основе такой классификации лежит отделение логики от представления, или интерфейса от реализации.
Формальное описание объекта «Активная модель»
При проектировании ВП возникает вопрос о целесообразности разграничения программного кода по уровням абстракции на начальных этапах разработки. Жизненный цикл (ЖЦ) ВП состоит из нескольких ключевых этапов: проектирование, прототипирование, разработка ВП, тестирование и отладка, развертывание, эксплуатация и снятие с эксплуатации.
На этапе проектирования будущего ВП разработчик (или команда разработчиков) должен определить первоначальное разделение. Оно характеризуется тем, что при его выполнении может быть не полностью определён набор сущностей предметной области, отображаемых на классы моделей. Эта неопределённость переносится также на классы сервисов (так как они осуществляют манипуляции с моделями), контроллеров (так как они осуществляют вызовы функций сервисов), представлений и т.д. Перенос определённости характеризуется свойствами взаимозависимостей различных частей веб-приложения.
Для разделения модулей на начальном этапе рекомендуется создать два модуля. Первый модуль носит название default (модуль по умолчанию), второй модуль может быть назван admin (административный модуль). В нём необходимо сосредоточить функции, касающиеся административной части ВП.
Существуют две методики по отделению административной части, инициирующей управляющие воздействия от остального программного кода. Первая методика[47] содержит рекомендации по использованию отдельного модуля для сосредоточения всех административных функций ВП. Вторая методика[48] рекомендует классифицировать административные функции по объекту их воздействия. Местонахождение таких функций однозначно определяется местонахождением моделей, к которым передается управляющее воздействие от них. Процесс формирования ЖЦ ВП связан с подпроцессами, происходящими на М-, К- и В-уровнях ВП, которые будут рассмотрены отдельно далее.
К-уровень является, как правило, вторым по величине (объему программного кода) после уровня представления уровнем абстракции ВП. На данный момент существует несколько методов разработки классов этого уровня (см. главу 1), однако все они обладают теми или иными недостатками. Основной недостаток связан с тем, что разработчику необходимо выбрать часть прототипа ВП, на которой надо основываться при проектировании и кодировании К-уровня: В-уровень (отображение пользовательского интерфейса на контроллеры) или же М-уровень (отображение концептуальных моделей предметной области на контроллеры). Любой выбор - это компромисс с его недостатками; в случае отсутствия выбора будет отсутствовать и чёткая архитектура, что неизбежно приведет к разработке программного кода, не удовлетворяющего требованиям качества (по стандарту ISO/IEC 9126:1991, ГОСТ Р ИСО/МЭК 9126-93)[49].
Существуют два основных метода разработки внешнего программного интерфейса ВП: удалённый вызов процедур (RPC) и передача состояния представления (REST). Метод RPC характеризуется большим на порядок количеством методов, чем ресурсов. А метод REST - наоборот, большим количеством ресурсов и меньшим количеством методов. Пусть NR -количество сетевых ресурсов, NM(Ri) - количество функций ресурса Rj Сетевым ресурсом называется концептуальная модель предметной области, доступная по сети вместе с функциями доступа к ней. Функцию зависимости количества ресурсов от количества методов назовем К-функцией ВП (рис. 30). Для этого под ресурсом будет подразумеваться контроллер, под функцией - действие контроллера.
В идеальном ВП, построенном по REST подходу, при необходимости добавления нового ресурса (контроллера) добавляется фиксированное количество методов этого ресурса, поэтому К-функция носит линейный характер (график 1 на рис. 30). При реальной разработке по REST (график 2 на рис. 30) сначала проходит этап отображения моделей на контроллеры, а после этого пополнение методов. В случае разработки по ЛРС-подходу сначала добавляется множество методов и ресурсов, а затем процесс добавления стабилизируется. Характер роста количества ресурсов и функций на начальном этапе важен потому, что в этот период закладывается основа архитектуры ВП, и цена ошибки (необходимое время на её устранение) в этот период выше, чем в последующем.
В ходе работы над диссертацией автором разработан «ресурсный» метод организации контроллеров ВП (рис. 31). Суть метода заключается в том, что необходимо производить разработку К-уровня, основываясь не на моделях, и не на видах, а на сущностях, над которыми планируется производить операции. Такие сущности будут являться ресурсами ВП, а внешний программный интерфейс к ресурсу будет называться контроллером ресурса.
Ресурс может быть моделью, видом или же сущностью, не требующей хранения в БД (например, сессии пользователя). Также ресурсом может выступать группа сущностей, или же группа ресурсов. В таком случае пользователь будет взаимодействовать с мета-ресурсом. Кроме того, при таком подходе К-уровень может контролировать представление ресурса в зависимости от того, от кого получен запрос. Для пользователя (П) возвращать ЯТМС-представление, а для внешнего ВП (ВП2 на рис. 31) его сериализованный вариант в одном из стандартных форматов (JSON, XML). ВП, как и любое другое ПС, можно оценить как количественно[50] (с помощью существующих метрик программного кода), так и качественно (с помощью экспертных оценок). Кроме известных на данный момент метрик (таких как количество строк кода, цикломатическая сложность), ПС в данной работе предлагаются новые метрики (мощности множеств уникальных имён контроллеров и функций-действий контроллеров), разработанные специально для оценки ВП приложений МВК класса. К-уровень ВП состоит из функций-действий контроллеров модулей. Для визуализации К-уровня предлагается следующий алгоритм: 1. Проводится кодирование названий модулей посредством присвоения каждому модулю последовательного уникального числового идентификатора. 2. Проводится обход всех контроллеров в модуле. Осуществляется кодирование названий контроллеров аналогично.
Методика аутентификации пользователя «брокер-провайдер»..
На данный момент существует множество провайдеров услуг внешней аутентификации. Основная причина использования адаптера внешней аутентификации в том, что у пользователя с большой долей вероятности есть открытая сессия в одном из внешних ВП: почтовые службы {Mail.ru, Yandex, Gmail), социальные сети (Facebook, Vkontakte, Odnoklassniki). Использование внешней аутентификации позволяет идентифицировать пользователя вообще без ввода им каких-либо данных, поэтому такое семейство методов называется быстрая аутентификация.
В то же время существуют ВП, представляющие собой посредника между зависимой стороной и провайдером авторизации, называемые брокерами. Они представляют программный интерфейс для приема параметров аутентификации от пользователя, собственно аутентификации его в приложении-провайдере и возвращении результата аутентификации зависимой стороне. На данный момент существует несколько крупных веб-приложений - брокеров внешней авторизации: Janrain [76], Loginza [77] и др. Но формат входного воздействия и выходного массива с результатом аутентификации у них различный.
В предлагаемом в данной диссертационной работе методе используется подход по реализации индивидуальных особенностей внешнего ВП (алгоритмы взаимодействия, количество и тип возвращаемых данных) в классе провайдере, а взаимодействие с брокером авторизации в классе брокера. Это позволяет, при необходимости добавлять новое внешнее приложение с минимальными трудозатратами, так как необходимо будет реализовать в программном коде только индивидуальные особенности добавляемого ВП. Задача аутентификации стороннего ВП может проводиться с помощью таких протоколов, как HTTPS. Аутентификация пользователей может проводиься также с помощью алгоритмов Kerberos, OpenAuth.
Предлагаемая архитектура обеспечивает уменьшение трудоёмкости внедрения нового способа аутентификации в существующее веб-приложение.
Одной из распространённых ситуаций при разработке ВП является необходимость интеграции разрабатываемого программного продукта с каким-либо сторонним приложением[78]. В Z MP-платформе используется БД MySQL, и многие сторонние веб-приложения также хранят данные в этой БД (или, по крайней мере, имеют соответствующий драйвер) Следовательно, существует возможность их интеграции. Основной проблемой при интеграции является работа с моделями пользователей. Как правило, модель пользователя в интегрируемой системе не соответствует модели пользователя в ВП.
Для решения этой задачи на данный момент применяется расширение модели интегрируемого приложения заключается в дополнении её множества атрибутов {АИНТЕГР) множеством атрибутов собственной модели (АСОБСТВ)-Однако для этого необходимо, чтобы множества не пересекались. Но у обеих моделей могут быть атрибуты первичных ключей, и они могут именоваться одинаково (например «id»). Тогда этот атрибут включается в результирующее множество: У данного метода есть существенный недостаток, стороннее веб-приложение не будет заполнять атрибуты из множества АСОБСТВ Предлагаемая методика дупликации СЧМУ-воздействий с использованием сервис-адаптеров для каждого веб-приложения соответственно (рис.51), позволяет отделить СЧМУ-операции моделей друг от друга. Единая точка входа управляющих воздействий - это функция сервиса, которая в цикле по классам-адаптерам вызывает соответствующую функцию в них. Важным условием использования такого подхода является поддержка транзакций в базе данных.
Вызов функций адаптеров будет выполняться внутри транзакции, и в случае, когда возникнет ошибка в одном из адаптеров, произойдет откат (отмена) транзакции. Это позволяет достичь атомарности для СЧМУ-воздействий для комплекса, состоящего из интегрируемой и собственной модели. Без обеспечения атомарности использование данного метода может привести к противоречивости данных моделей. Аналогичным образом возможна интеграция с другими моделями предметной области интегрируемого ВП.
В данной главе были изложены предлагаемые практические методики разработки веб-приложения с использованием свободных интернет-технологий и созданные способы реализации теоретических основ из первой главы. Обобщая содержание главы, можно сделать следующие выводы: 1. Создан алгоритм двухэтапной загрузки веб-приложения по предлагаемой архитектуре. Определено понятие ресурса загрузки. 2. Предложен алгоритм двухступенчатой классификации входных воздействий, который позволяет разграничить права доступа пользователей с определёнными ролями к определённым векторам управления веб-приложением. Возможности «ролевого» и «группового и индивидуального» определения доступа позволяют гибко конфигурировать параметры доступа пользователей. 3. Разработана методика интернационализации данных и интерфейса многоязычного веб-приложения, оптимизирующая хранение языковых данных, а также генерацию выходного воздействия на основе данных интернационализации интерфейса. 4. Предложенная автором методика организации п-уровневого кэширования по разработанным уровням абстракции веб-приложения позволяет увеличить его быстродействие. Предлагаемая инвалидация методом автоматического вытеснения позволяет сохранить непротиворечивость данных в КЭШе с информацией в основном хранилище при максимально полном использовании кэширования. 5. Определена организация жизненных циклов объектов веб-приложения с минимальным количеством состояний. Это необходимо для учёта особенностей развития веб-приложений в динамике. 6. Предложенная автором методика аутентификации пользователя «Брокер-провайдер» позволяет проводить внешнюю аутентификацию пользователей в сторонних веб-приложениях.
Изменение характеристик быстродействия системы объектно-реляционного преобразования
ВП должно работать в инфраструктуре платформы LAMP, на базе операционной системы Linux. В качестве основной ОС на испытательном стенде была выбрана Ubuntu Linux Server Edition 10.10 64bit. Программный веб-сервер Apache или Nginx. Предпочтение при выборе отдается отечественному программному обеспечению Nginx из-за повышенной скорости обработки запросов. В качестве БД применялась MySQL или сборка Percona Server, содержащая набор модификаций, увеличивающих быстродействие БД. Использовался интерпретатор языка РНР 5.3.2 в форме бинарного пакета php5-fpm для работы в FastCGI режиме. В качестве системы кэширования программного РНР кода в байт-код использовалась программа Аре.
Предметная область разрабатываемого в рамках диссертационной работы ВП представлена объектами реального мира, участвующими в процессе торговых отношений между физическими (пользователями) и юридическими лицами (компаниями). Предметом отношений выступают товары и заявки на покупку, являющиеся логической противоположностью товаров.
Структурная составляющая ВП представляет собой совокупность объектов, моделирующих сущности предметной области, над которыми ВП осуществляет определённые действия. Множество объектов (хранимых в отношениях БД) делится на две категории: объекты предметной области и служебные объекты, не имеющие отношения к предметной области. Объекты предметной области могут иметь статичную природу, а именно не изменяются со временем. Отношения (таблицы) таких объектов называются справочниками. Другие же объекты могут изменяться в рабочем цикле приложения, такие объекты называются динамическими.
Одним из требований при проектировании программных архитектур является модульность. Она позволяет осуществить декомпозицию задачи на подзадачи, их распределение по модулям, внутреннюю связность модулей и связанность между собой[79]. Модули следует разрабатывать максимально независимыми друг от друга, чтобы была возможность в короткие сроки перенести модуль из одного ВП в другое, а также, для избегания дублирования кода. Модуль состоит из нескольких частей (рис.52).
Классы-контроллеры (Controllers) - это файлы вида Controller.php в папке /controllers модуля, которые отвечают за обработку запросов пользователей, вызов функции моделей. При этом контроллеры разделены по набору функций. Контроллер по умолчанию модуля называется также как и
Файлы-виды {Views) отвечают за отображение информации моделей (или данных, возвращённых сервисами) для пользователя или для другого программного обеспечения. В качестве примера другого ПО можно привести клиента для мобильных платформ {iPhone, Android). Классы-виды делятся на четыре типа: шаблоны {templates), непосредственно виды {views), частичные виды {partial views), формы {forms).
Шаблоны являются видами первого порядка, т.е. внутри них могут обрабатываться другие виды. Внутри обычных видов другие виды обрабатываться (заполняться данными и отображаться) не могут, кроме случая, когда используются «частичные виды» {partial views). Частичные виды используются в том случае, если необходимо отобразить повторяющиеся данные, например, для отображения иерархического меню.
Классы-формы (forms) представляют собой классы, которые отвечают за преобразование формы в страницу и её валидацию (проверку введенных данных) на стороне сервера. Формы удобны тем, что, единожды разработав, их можно повторно использовать, так как их интерфейс стандартизирован.
Классы-модели делятся на два типа - это базовые модели (объекты, отражающие таблицы БД), и модели логики предметной области. Базовые модели содержат в себе описание структуры модели, производит «маппинг» (отражение) таблиц реляционной базы данных на объекты языка программирования (РНР).
Классы-сервисы (Services) предназначены для разгрузки моделей. Сервисы представляют собой классы-одиночки. Они являются наследниками от класса Default_BaseService. Получить объект сервиса можно с помощью вызова функции Module_ServiceName::getInstance(), которая вернет объект сервиса, создав его в случае отсутствия. Сервисы, как правило, используются для операций с моделями. Очень часто в них реализована логика предметной области системы, для того чтобы не загромождать классы моделей. В сервисах располагаются функции работы с группой моделей, поиск по моделям, различные варианты фильтрации, сортировки, изменения и сохранения группы моделей. Если функция работает с единичной моделью и не выполняет комплексных действий, то она размещается в самой модели.
Все адреса сайта и ссылки на них формируются через систему маршрутов. Маршрут - это соответствие между Ж-адресом и вектором {модуль, контроллер, действие} и определение значений для переменных, входящих в состав маршрута. Для того чтобы система была целостной, необходимо не только определять все адреса через маршруты, но и производить формирование ссылок с использованием маршрутов. Это производится при помощи класса-помощника вида. Чаще всего формирование ссылок производится в файлах-видах (views) следующим образом (рис. 53):
