Содержание к диссертации
Введение
1 Анализ существующих моделей данных и СУБД 8
1.1 Требования к СУБД для разработки систем управления виртуальными представительствами 11
1.1.1 Поддержка распределенной структуры БД 13
1.1.2 Поддержка хронологий данных 15
1.2 Обзор существующих моделей данных и программных средств 18
1.2.1 Реляционная модель 18
1.2.2 Объектная модель *. 22
1.2.3 Темпоральные модели 27
1.3 Дополнительные предположения предметной области 30
Постановка задач диссертационного исследования 33
2 Разработка расширенной реляционной модели данных 35
2.1 Реляционная модель 35
2.1.1 Структура данных 35
2.1.2 Ограничения целостности 37
2.1.3 Операции реляционной алгебры 38
2.2 Расширенная реляционная модель данных 42
2.2.1 Структурная компонента 42
2.2.2 Целостная компонента 50
2.2.3 Манипуляционная компонента 51
2.3 Возможности 62
2.3.1 Синхронизация 62
2.3.2 Важный частный случай полной системы действий . 69
2.3.3 Типичные примеры действий 72
Выводы 72
3 Алгоритмизация и реализация расширенной реляционной СУБД 74
3.1 Реализация структурной компоненты 75
3.1.1 Представление расширенного реляционного отношения 75
3.1.2 Представление действий и потока действий 76
3.2 Реализация манипуляционной компоненты 83
3.2.1 Реализация расширения классических реляционных операций 83
3.2.2 Реализация операций над действиями и потоками действий 86
3.2.3 Реализация операции выполнения действия 88
3.2.4 Реализация операции получения ревизии отношения . 90
3.2.5 Реализация операции синхронизации двух БД 92
3.3 API 97
3.4 Сравнительный анализ эффективности 98
Выводы 101
4 Создание системы управления виртуальными представитель ствами 103
4.1 Особенности реализации системы 103
4.2 Модифицированная схема M.VC 108
4.3 Подсистемы 111
4.3.1 Подсистема вывода пользовательского интерфейса 111
4.3.2 Подсистема работы с SQL-сервером 114
4.3.3 Дополнительные подсистемы 117
Выводы 119
Заключение 120
Библиографический список 122
Приложения
- Требования к СУБД для разработки систем управления виртуальными представительствами
- Структурная компонента
- Реализация манипуляционной компоненты
- Подсистема вывода пользовательского интерфейса
Введение к работе
Актуальность темы. Информационные системы моделирования и управления всевозможными процессами, основанные на системах управления базами данных (СУБД), в настоящее время используются практически повсеместно. Важным примером подобных систем являются системы управления виртуальными представительствами (сайтами). К современным системам подобного рода предъявляются требования распределенности и хронологичности (т.е. предоставления возможности просмотра, модификации, и удаления любой версии данных, сохраняемой в системе, а также операций над ними). Первое требование обуславливается географической распределенностью организации-владельца представительства и размещающей сайт организации; второе - ростом важности публикуемых на сайте данных и необходимостью контроля доступа к ним.
Для решения задачи построения распределенных и хронологических систем предоставляемых существующими СУБД средств оказывается недостаточно: практически не решается задача синхронизации гетерогенных БД; интегрирование управления синхронизацией БД в приложение затруднено; не предусмотрено никаких средств для манипулирования хронологиями данных и действий. Лежащая в основе большинства СУБД реляционная модель, а также другие известные модели данных (сетевая, иерархическая, объектные, темпоральные), в свою очередь, никак не учитывают распределенной и хронологической структуры данных.
Из сказанного следует, что выбор и обоснование модели данных, учитывающей распределенную и хронологическую структуру, и создание на ее основе инструментария для разработки виртуальных представительств, отвечающих потребностям настоящего времени, является актуальной задачей.
Диссертационная работа соответствует научному направлению ЛГТУ "Разработка теории проектирования информационных систем".
Цель и задачи исследования. Целью диссертационной работы является разработка расширенной реляционной модели данных и программного обеспечения распределенной хронологической информационной системы управления виртуальными представительствами.
Исходя из данной цели, определены следующие основные задачи:
разработка логической модели данных, ориентированной на поддержку распределенных хронологических БД;
разработка алгоритмов и методов синхронизации БД и доступа к хронологии данных и операций;
разработка программного обеспечения, реализующего управление распределенной хронологической БД, и проведение на его основе сравнительного анализа скоростных характеристик существующих реляционных СУБД и разработанной СУБД;
разработка базовых программных компонент, обеспечивающих типовые элементы функциональности для класса задач создания виртуальных представительств и систем управления ими.
Методы исследования. В работе использованы методы реляционной
алгебры, теории множеств, теории графов, теории построения интерпретаторов, модульного, структурного и объектно-ориентированного программирования, а также вычислительные эксперименты.
Научная новизна. В диссертации получены следующие результаты, характеризующиеся научной новизной:
расширенная реляционная модель данных, отличающаяся использованием элементов и операций расширенной реляционной алгебры, обеспечивающая представление хронологий данных и действий над данными;
алгоритм проектирования Web-приложений, расширяющий возможности введения семантических связей между экранными формами, отличающийся использованием для каждой формы многофазного контроллера;
способ разработки интерфейсов Web-приложений, обеспечивающий сокращение трудоемкости разработки за счет реализации процедурного подхода к визуализации отдельных Web-компонент;
метод проектирования распределенных хронологических СУБД, обеспечивающий повышение эффективности их создания и внедрения за счет применения расширенной реляционной модели данных и механизма ее отображения в реляционные отношения.
Практическая ценность результатов диссертационной работы. Разработан программный комплекс для сравнительного анализа эффективности основных операций реляционных СУБД, а также реализации СУБД, базирующейся на расширенной реляционной модели.
С применением предложенного алгоритма проектирования приложения и подхода к разработке интерфейсов разработан программный комплекс для создания и управления виртуальными представительствами, содержащий подсистему управления распределенными хронологическими базами данных, основанными на расширенной реляционной модели.
Реализация и внедрение результатов работы. Разработанный программный комплекс для создания и управления виртуальными представительствами внедрен в деятельность ведущего оператора связи Липецкой области «Липецкэлектросвязь» (филиал ОАО «ЦентрТелеком») и используется для разработки Web-сайтов как самого филиала «Липецкэлектросвязь», так и для сторонних заказчиков.
Результаты диссертационной работы используются в учебном процессе ЛГТУ при изучении студентами специальности 073000 «Прикладная математика» дисциплин «Базы данных» и «Системное и прикладное программное обеспечение».
Апробация работы. Теоретические и практические результаты, полученные в процессе исследования, докладывались и обсуждались на VII-й и VIII-й Международной электронной научной конференции «Современные проблемы информатизации в непромышленной сфере и экономике» (Во-
ронеж, 2002-2003), на семинарах, проводимых Липецким региональным отделением Российской ассоциации искусственного интеллекта (Липецк, 2000-2003), а также на научных семинарах кафедры прикладной математики ЛГТУ.
Публикации. По материалам диссертационной работы опубликовано II работ, в том числе 9 без соавторов. В [9] лично автором предложен метод реализации СУБД, построенной на расширенной реляционной модели данных, основанный на использовании реляционной СУБД; в [10] предложены алгоритм проектирования Web-приложений, модифицирующий схему MVC (Model-View-Controller, Модель-Отображение-Контроллер), и процедурный подход к созданию интерфейсов виртуальных представительств.
Структура и объем работы. Диссертация состоит из введения, четырех глав и заключения, библиографического списка из 102 наименований. Основная часть работы изложена на 121 странице машинописного текста, содержит 12 рисунков и 7 таблиц.
Требования к СУБД для разработки систем управления виртуальными представительствами
Многие информационные системы, не исключая систем управления виртуальными представительствами, имеют, как правило, следующую трехуровневую внутреннюю архитектуру; 1) база данных, хранящяя всю доступную системе информацию, 2) бизнес-логика, 3) пользовательский интерфейс. Связи между уровнями изображены на рис. 1.1.
Для практической реализации уровня БД и интерфейса на данный момент уже существует довольно развитый готовый инструментарий. Так, Реляционная модель
Бизнес-логика базы данных в подавляющем большинстве случаев организуются при помощи той или иной системы управления базами данных (СУБД); для реализации Web-интерфейса используется какой-либо Web-ориентированный язык и (опционально) библиотека шаблонов для этого языка; для создания "обычного" интерфейса — визуальная среда разработки ([48]) или библиотека под целевой язык и операционную систему. При этом выбор довольно широк - одних только распространенных СУБД и языков наберется по десятку-другому, как и библиотек шаблонов для каждого Web-ориентированного языка из этого десятка. Различаются они непринципиально, в основном, наличием или отсутствием тех или иных возможностей.
Для реализации уровня бизнес-логики инструментарий также существует, и выбор едва ли не разнообразней. Действительно, на рынке присутствуют минимум три технологии, одновременно достаточно общеизвестные (и как следствие, достаточно распространенные) и подходящие для реше ния задачи строгого выделения бизнес-логики в отдельную, независимую часть приложения - а именно, EJB, CORBA ([44]) и ADO+ [53] (включая его предшественников - COM, DCOM, ADO). Конкретных реализаций данных технологий (EJB-контейнеров, CORBA-брокеров) также существует по несколько штук.
Однако, несмотря на разнообразие существующих средств, требования, налагаемые современными системами управлениям виртуальным представительствами все еще удовлетворяются не в полной мере. Опишем данные требования подробнее.
Распределенные БД возникают в случаях, когда по каким-то причинам выгоднее хранить информацию в географически или логически различных СУБД. Основных причин две: географическая распределенность и ограниченная мощность одного сервера ([12]).
Отметим, что существует и альтернативный подход к организации распределенных систем, не требующий создания распределенной БД. Однако в этом случае, во-первых, во всех узлах системы требуется иметь постоянную и достаточно быструю связь с сервером БД, что далеко не всегда возможно; и, во-вторых, клиенты строго зависят от выбора конкретного сервера (хотя определенные шаги в этом направлении уже предпринимаются - к примеру, разрабатываемый стандарт RDA/SQL ([32])).
Интересующий нас вариант касается ситуации с однотипными распределенными географически филиалами одного предприятия. При работе с данными, как и с другими материалами, удобнее всего хранить их там, где непосредственно происходит работа. Однако, поскольку данные логически связаны, должна быть возможность оперировать всеми данными как единой базой данных. Преимуществами распределенной системы являются эффективность обработки (в результате того, что не надо тратить ресурсы на соединение с единственным узлом, хранящим данные) и расширенные возможности доступа (при необходимости, все данные могут быть получены).
Поскольку часть данных используется несколькими узлами, копирование отдельных отношений или их фрагментов может повысить эффективность работы. Этот процесс называется репликацией ([38]). При невозможности соединения с некоторыми из узлов доступность данных повышается за счет наличия нескольких копий. Однако, для поддержания данных в согласованном состоянии необходимо следить за тем, чтобы обновления всех реплик происходили одновременно (распределенные транзакции). В этом смысле данные становятся менее доступны, т.к. неудачей окончится любая попытка модификации данных, копия которых в данный момент является недоступной. Поэтому большая часть продуктов, не требующих работы в реальном времени (в отличие от, например, продажи авиабилетов или систем управления конвейером), на практике используют асинхронную репликацию данных, в которой распространение обновлений откладывается на некоторое более позднее время ([41]). В частности, поддерживает асинхронную репликацию отечественная СУБД "Линтер" ([17]). Процесс приведения двух копий одного отношения к одному состоянию называется синхронизацией. Ситуации, в которых невозможно принять все обновления (добавления, удаления) на каждой копии, называется конфликтом синхронизации. После завершения синхронизации и разрешения всех конфликтов данные можно опять считать согласованными.
Правила разрешения конфликтов синхронизации зависят, вообще говоря, от логики конкретного предприятия: например, транзакции пользователя А должны всегда "побеждать" конфликтующие транзакции пользователя В. Поэтому необходима возможность задания разнообразных правил разрешения конфликтов.
Системы управления виртуальными представительствами являются типичным примером прикладной задачи, использующей распределенную БД, синхронизация между локальными узлами которой происходит асинхронно, с некоторой периодичностью. Сходными примерами могут служить сети магазинов, офисов сервисной компании, и так далее. Однако в случае виртуальных представительств некоторые проблем особенно актуальны. В частности, в точке размещения виртуального представительства далеко не всегда возможно использовать СУБД того же производителя и версии, что и в других точках ([7]); для различных пользователей виртуального представительства скорее всего нет возможности регистрировать различных пользователей базы данных с разными правами доступа; транспортные протоколы для передачи данных программному обспечению представительства могут быть строго ограничены (например, доступ только по HTTP с ограничениями на размер запроса); и так далее.
Подводя итог, можно сформулировать следующие требования к поддержке распределенной структуры БД: - поддержка асинхронной репликации и синхронизации; - поддержка синхронизации гетерогенных БД; - поддержка настраиваемых приложением правил разрешения конфликтов; - возможность использования нестандартного траснпортного протокола для передачи данных, необходимых для синхронизации.
Структурная компонента
Обозначим через R.elx множество всех отношений со схемой X.
Схему базы данных будем рассматривать как набор базовых переменных-отношений с фиксированной схемой DB — {Vi, 14,... ,Vn}, набор ограничений целостности W = {Wj(Ri, Л2,Rn)}j=i,...,m и набор базовых действий BF ([6, 8]). Множество состояний БД, в которых значения
1в реляционной алгебре пустое множество бывает с разным заголовком переменных-отношений Vi принимают значения некоторых отношений Щ обозначим через D = {{і?і, Я2,..., Rn}} Под обозначением W будем понимать, в зависимости от ситуации, и ограничение целостности, и правильно записанное выражение нашей реляционной алгебры И7 : D —+ Relx, переводящее состояние базы данных D в отношение со схемой X. Ограничение W означает требование выполнения соотношения W{R\,R2 ..,Rn) = 0. Так же W можно рессматривать как предикат, который принимает значение ИСТИНА, если W(Ri, Я2,..., Rn) = 0 и значение ЛОЖЬ в протичном случае.
Чтобы воспроизвести функциональность обыкновенной реляционной БД, набор базовых действий должен включать полную систему операций модификации. Это означает, что из любого допустимого состояния БД можно перевести в любое другое возможное после этого состояние.
Например, при отсутствии ограничений целостности любую модификацию можно выразить через последовательность добавлений и удалений кортежей, т.е. в качестве базовых могут быть выбраны все возможные действия-удаления delifa = {Ri = Ri — = (-)}. к0 принимает значения первичного ключа К и действия-добавления insert = {Ri := Ri U {t}}, t принимает любые значения на fj dom А Тогда, к примеру, операция обновления будет представляться композицией двух операций: удаления старой записи и добавления новой. В случае, если ограничения целостности имеют место, разложение по delifo и insert может оказаться невозможным. В современных БД для таких случаев используют отложенную проверку ограничений целостности.
Использование данных заключается в получении результатов произвольных запросов, описываемых правильно построенными выражениями реляционной алгебры и применяемых к произвольному заданному варианту состояния БД.
Различные состояния БД будут различаться при помощи версий 5 из конечного множества S посредством функции d : S — D, т.е. запись d[s] = D будет означать, что состояние s-й версии БД равно D. Аналогично обозначим через Vi[s] значение переменной-отношения Vt в d[s]. Это множество будет являться конечным (следовательно — дискретным) подмножеством всех моментов времени. На множестве версий задано отношение частичного порядка , означающее хронологическую последовательность состояний, т.е. (si s2) = (Зі71 F){F(d[si\) = rf[s2]), и имеется наименьший элемент s0, т.ч. Vs Ф s0 s0 s. Функция d будет описывать хранящиеся в БД данные.
Введенное понятие версии отличается от понятий версии и многоверси-онности, используемого при реализации транзакций в реляционных СУБД ([57, 101]). Введенное понятие есть понятие логического уровня, маркирующее некоторое постоянное состояние всей БД; связанной же с многоверси-онностью понятие версии есть понятие физического уровня, маркирующее внутреннюю для СУБД версию кортежа.
На каждом узле ведение БД осуществляется последовательным применением операции DBApply к экземпляру БД. Последовательное применение этой операции порождает линейно упорядоченное множество состояний и единственный простейший поток действий, представляющий смену состояний. Пусть SQ — момент, когда данные на всех узлах совпадали, и DQ = d[so] — состояние БД в этот момент. На каждом из к узлов поток действий fi,i = 1,...,& порождает состояние Д — DBFlowApply(D0, ft).
По смыслу действия в БД отражают реально происходящие действия (изменения) в мире, поэтому истинное состояние БД можно получить, выполнив над ее "начальным" состоянием действия всех потоков /,-. Понятно, что результат применения действий в общем случае зависит от порядка, поэтому основным вопросом при синхронихации будет для нас являться коммутативность операции композиции действий. Рассмотрим далее коммутативность указанной операции, вопрос синхронизации двух БД (новая операция Зупс(Т і,Т 2)) и вопрос синхронизации данных большего числа узлов Syncn{puV2,..., АО-Коммутативность композиции действий
Должна являться коммутативной операцией вупс(Т х,Т 2) = Sync(T 2,Vi), так как задача формулировалась для однородной распределенной БД и все узлы являются равнозначными.
Дано начальное состояние БД DQ = CI[SQ] и потоки действий / = «Fi,9i),...,(Fn,en}) и д = ( Gi,0i),..., Gm,0jn)), т.ч. s{nin = s3min = s0. на каждом из которых задан частичный порядок. В результате синхронизации нужно получить поток действий, включающий в себя все действия из обоих потоков в "правильном" порядке. Здесь приходится ответить на два вопроса:
- Что значит все действия
- Какой порядок можно назвать правильным
Ответ на первый вопрос кроется в идентификации действий. Понятно, что для каждого потока все действия являются строго различными и все должны войти в поток результирующего расширенного отношения. Действия же из разных потоков, для которых Fi = Gj и 0,- = -dj можно рассматривать как различные или как одно и то же действие. Если действия рассматриваются как отдельные, совпадение их схем и параметров может повлиять на работу с ними только в силу возможности установления свой ства коммутативности при одинаковых значениях параметров (см. стр. 63), которая в данном случае будет обозначать идемпотентность применения действия. Если же рассматривать действия как одно, объединение частично упорядоченых множеств действий станет не таким тривиальным. В этом случае уменьшится количество действий и понизится размерность задачи, но появятся ситуации циклов (в одном потоке задан порядок Fi / F2, а в другом — F 2 д Fi), разрешение которых потребует разделения или удаления одной из операций. Мы будем считать это достаточным доводом в пользу отказа от возможности эквивалентности действий, выполненных на различных узлах.
Настройка автоматического разрешения конфликтов синхронизации Настройка автоматического разрешения конфликтов синхронизации заключается в задании процедуры однозначного выбора действия, которое необходимо отменить для разрешения конфликта. Основными требованиями к применяемым стратегиям должны быть условия коммутативности и ассоциативности получаемой в результате операции синхронизации.
Симметричную операцию дает также стратегия, в которой производится откат всех конфликтующих действий. Она опять-таки не будет ассоциативной: если на узлах 1 , была выполнена операция гпвц, а на узле Е/3 — deli t, то при выполнении Зупс(Зупс(Т і,Т 2),Т з) мы получим OF, а при Sync(Vu Sync(V2),V3) — гпзіл.
Удобным методом являются присваивание каждому действию некоторого ранга (в зависимости от узла, на котором оно было выполнено, или пользователя, являющегося автором произведенных изменений). Среди кандидатов на откат выбирается то действие, ранг которого ниже. При подобной стратегии симметричность операции синхронизации также имеет место.
Ассоциативность по прежнему будет отсутствовать, если конфликт порожден не двумя, а большим числом действий. В этом случае нельзя точно сказать, какие действия следует откатить, а последовательная парная синхронизация может привести к откату лишних действий или действия, не обладающего минимальным рангом.
Приведем модифицированный вариант этой стратегии. В качестве ранга действия можно рассматривать наибольший из рангов зависимых от него действий. Операция останется коммутативной, но ассоциативности будет нанесен еще один удар: при таком подходе происходит дополнительное смешение различных конфликтов и результат получается зависящим от порядка их разрешения.
Реализация манипуляционной компоненты
Стандартные реляционные операции в рамках языка SQL могут быть использованы в двух контекстах. Первый контекст - вычисление выражения и передача вычисленного значения клиенту (SQL-сервера), то есть выборка. Второй - вычисление выражения и присвоение его значения некоторому отношению (таблице, в терминах SQL-сервера).
В связи с избранной структурой хранения данных, все запросы-выборки могут быть непосредственно переданы SQL-серверу. Таким образом, в контексте выборки реализация всех стандартных реляционных операций остается практически неизменной.
С учетом того, что данная система действий является полное (то есть произвольное выражение реляционной алгебры можно декомпозировать на эти операции), было решено в первой версии из модифицирующих актуальные версии реляционных отношений расширенной модели действий ограничиться следующими функции API. Ассоциативный массив (хэш с ключами-строками), ключи которого есть строки-названия столбцов, а значения содержат значения атрибутов кортежа. $id
Пример, оформляющий описанное ранее присвоение в виде действия расширенной модели, приведен в приложении 3. Определенное усложнение операций со вложенными выборками и обработка их "вручную" на клиентской стороне, к сожалению, необходимы, так как подсистеме управления данными для возможности сохранения данных для отката необходима информация о результатах выборок, но сама эта подсистема располагается в данной реализации также на клиентской стороне. При дальнейшем развитии данной реализации возможно, при необходимости, инкапсулировать получающуюся декомпозицию внутрь функции xsql_query() (как это было бы сделано при реализации модели полностью на стороне сервера). 3.2.2 Реализация операций над действиями и потоками действий
Исходя из требований к разрабатываемой системе в целом, были определены следующие требования к подсистеме управления данными:
1) Возможность просмотра истории действий, модифицировавших данную актуальную запись.
2) Возможность просмотра истории действий, модифицировавших данную удаленную запись.
3) Возможность отката действий.
4) Возможность проведения синхронизации истории действий и актуальных данных между узлами распределенной базы данных.
Откатывает действие, идентифицирующееся данным $trtid. Возвращает false в случае ошибки, true в случае успеха. Алгоритм работы функции таков:
- Проверить наличие транзакции $trtid. Проверить ее тип. Вернуть false в случае ошибок. Загрузить данные транзакции в случае успеха.
- Загрузить все транзакции, модифицирующие те же записи, что и откатываемая (набор таких транзакций может оказаться пустым).
- Извлечь список изменившихся атрибутов ($changed_Hst) из откатываемой транзакции.
- Убрать из всех загруженных транзакций поля, отсутствующие в $changed_list.
- Для каждого атрибута, проанализировать коды операций в списке загруженных транзакций. Вернуть false в случае наличия зависимых присвоений. Рассчитать новое актуальное значение в случае их отсутствия.
- Обновить запись посредством проведения действия с типом, рав ным конкатенации префикса отката (e.g., "rollback") и типа откатываемой транзакции.
В данный момент, действия с типом, начинающимся с префикса отката, не могут быть откачены и не могут быть проведены явно. "Откат отката" возможно (и планируется) реализовать проведением "виртуального" действия с типом, равным типому исходно откаченного действия. Невозможность явного проведения действия с типом, начинающимся с префикса отката, обусловлена необходимостью различать (как минимум для целей предоставления пользователю системы корректной информации) "обычные" действия и откаты, и, следовательно, это ограничение также может при необходимости быть устранено вынесением флага из префикса типа в отдельный атрибут действия.
Функции xsql_sync_build_packet() и xsql_sync_apply_packet() будут описаны ниже, в части, описывающей реализацию синхронизации.
Подсистема вывода пользовательского интерфейса
Работа пользователя ПК с данными подразумевает их вывод (четвертая фаза обработки запроса в модифицированной схеме MVC). По опыту, код вывода пользовательского интерфейса (user interface, UI) занимает порядка половины исходного текста всего Web-приложения и является одной из наиболее часто изменяемых компонент последнего. Поэтому важно организовать вывод UI так, чтобы его изменение, добавление и поддержка оставались достаточно нетрудоемки независимо от объемов исходного текста. Можно перечислить следующие требования к подходам организации UI:
1) высокая скорость разработки; 2) поддерживаемость кода; 3) изоляция логики и оформления; 4) возможность изменения оформления (в том числе полного). В рамках Web-приложений как таковых и в приложении к языку РНР в частности, известны следующие распространенные подходы к задаче вывода интерфейса: 1) непосредственный вывод HTML-кода интерфейса операторами печати; 111 2) чередование исходного кода приложения и встраиваемого в него вывода HTML-кода интерфейса (для позволяющих такое чередование языков); 3) использование шаблонов (templates) для формирования HTML (например, Smarty); 4) построение в памяти DOM-дерева HTML-документа из стандартных классов и последующая его трансформация в HTML (например, PEAR::HTML); 5) формирование XML-документа с данными и последующая трансформация его в XHTML с использованием XSL-преобразования ([59]). Все известные подходы, как показано автором в [11], не вполне удовлетворяют имеющимся требованиям. По этой причине в ходе разработки системы был создан и успешно применен новый, не встречавшийся автору в Web-приложениях, подход, заключающийся в следующем:
1) Формируется список различных элементов интерфейса, (как атомарных, так и композитных), используемых в данном Web-приложении. 2) Для каждого конкретного элемента сформированного списка создается процедура либо набор процедур визуализации, выводящая либо возвращающая HTML-разметку, соответствующую данному элементу. 3) Любой вывод любого элемента интерфейса происходит строго при помощи созданных процедур. Результатом применения подхода в рамках разработанного ПК явился процедурный API построения интерфейсов (UI API), функции которого, в отличие от известных API, соответствуют не данным и не элементам HTML, а базовым элементам типичных Web-интерфейсов. В результате использования UI АРІ в реализованном ПК: - осуществляется разделение языка программирования и HTML (вся HTML-разметка проекта существует только внутри реализации Ш API); 112 - код визуализации расположен в одном файле с кодом, подготавливающим данные для визуализации, что часто оказывается удобнее разделения на разные файлы; - значительно упрощено изменения оформления пользовательского интерфейса, (для его реализации необходимо и достаточно заменить лишь реализацию UI API); - стало возможно реализовывать более сложную логику визуализации, так как она происходит на целевом языке, который, как правило, обладает большими выразительными средствами по сравнению с языком шаблонов. Каждая функция UI API реализована в двух вариантах. Первый вариант немедленно выводит элемент на печать, второй возвращает текстовую строку с кодом элемента. Наличие первого варианта позволяет как угодно комбинировать стандартные элементы (например, форма в одной из ячеек таблицы, вложенной в другую таблицу, и т.д.).
Проведен сравнительный анализ подходов к разработке Web-интерфейсов, основанный на экспертных оценках. Результаты анализа приведены в таблицах 4.1 и 4.2; они подтверждают сделанные выше выводы. Это позволяет рекомендовать процедурный подход для решения задачи создания Web-интерфейсов.
Предложенный процедурный подход, его конкретная реализация в рамках программного комплекса и части некоторых других реализованных алгоритмов основываются на методах и алгоритмах, предложенных автором в области трехмерной графики ([2, 3, 4]). АРІ для создания интерфейсов предложен по аналогии с API визуализации 3D-cueH, путем переноса и развития методики процедурного задания отдельных элементов с задачи описания ЗО-сцены на задачу построения Web-интерфейсов. Предложенные методы и алгоритмы также используются в реализации переносимого модуля ЗИ-графики, необходимого для создания публикуемой на сайте графической информации.
В завершение перечислим группы функций реализованного в ПК UI API. - HTML-экранирование и разэкранирование; - вывод текста (с различным форматированием); - вывод компонент для ввода и проверка дат; - вывод отдельных ссылок и панелей навигации (toolbar); - вывод таблиц различных типов оформления; - вывод форм {в том числе всевозможных компонент ввода - текстовых строк, паролей, блоков текста, загрузки файлов, выпадающих списков, кнопок, и т.п.); - вывод иерархических структур (деревьев); - вывод списков; - вывод компонент для организации постраничного просмотра; - вывод журнала системных сообщений.
Данная подсистема представляет собой уровень абстракции, находящийся между всеми остальными функциями (в том числе функциями под 114
Необходимость во введении данного уровня абстракции обуславливается следующими двумя причинами.
Во-первых, названия идентичных по смыслу функций в языке РНР различаются в зависимости от используемой СУБД, поэтому добавление лишнего уровня абстракции позволяет ощутимо облегчить задачу переноса приложения с одного SQL-сервера на другой: в случае с использованием выделенной подсистемой доступа к СУБД достаточно перенести лишь ее саму и небольшую часть запросов - в то время, как в противном случае необходимо переработать всю работу с базой данных. Для решения этой задачи уже существуют различные библиотеки, в том числе поставляемые вместе с языком РНР (ADODB, PEAR::DB); однако они страдают от синтаксической избыточности наряду с отсутствием некоторой необходимой функциональности.
Во-вторых, одним из наиболее часто срабатывающих методов получения несанкционированного доступа к Web-приложению на нетипизированном языке (в том числе РНР) является манипуляция HTTP-запросом с целью изменить семантику того или иного вызываемого приложением SQL-запроса. Например, если приложение использует следующий (ошибочный, но очень типичный) код для стирания одного доступного пользователю объекта: проверка будет пройдена успешно, а запрос удалит все объекты, в том числе и не принадлежащие пользователю.
Но добавление такой проверки, разумеется, также требует написания лишнего уровня абстракции (в данном примере этим уровнем являются.
Выше были подробно описаны те особенно важные для приложения подсистемы, интерфейс, функциональность и реализация которых заметно отличаются от используемых в настоящее время в системах аналогичного рода. О всех остальных подсистемах подобного сказать нельзя, так что подробное их описание не имеет смысла. Однако, для полного понимания предоставляемых всех системой возможностей необходимо иметь общее представление о реализованной функциональности. В связи с этим, приведем краткий список всех имеющихся подсистем. Подсистемы перечислены в алфавитном порядке.
