CC BY
55
приложения. Естественно, при этом будет удалена и функциональность, реализуемая этим вертикальным модулем.
Объектная модель, реализующая интерфейс СУБД приложений, была реализована в различных инструментальных средах (FoxPro, Delphi). Опыт ее использования показал плодотворность и эффективность этой модели. Особенно заметен эффект ее использования на этапе сопровождения приложения, когда надо вносить изменения в уже работающее приложение.
ЛИТЕРАТУРА
1. Горбунов-ПосадовММ. Расширяемые программы. М.: Полиптих. 1999. 336с.
2. Extensible Markup Language (XML) 1.0 W3C Recommendation 10-February-1998, http://www.w3.org/TR/1998/REC-xml-19980210
3. Фуксман А.Л. Технологические аспекты создания программных систем. М.: Статистика. 1979. 184с.
А.А. Букатов, В.А. Шапиро, О.В. Шаройко
ТЕХНОЛОГИЧЕСКИЕ АСПЕКТЫ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ И УПРАВЛЯЮЩИХ СИСТЕМ
На примере создания системы учета загрузки каналов распределенной информационной сети РГУ рассматриваются некоторые технологические аспекты создания распределенных информационных и управляющих систем, связанные с обеспечением возможности дальнейшего развития таких систем как в плане расширения их функциональных возможностей, так и в плане адаптации к изменениям структуры информационной базы и/или объектов управления, а также к изменению уровня нагрузки на систему.
При построении архитектуры системы выполняется декомпозиция системы в вертикальных и горизонтальных плоскостях. Горизонтальная декомпозиция выполняется в соответствие с моделью трехслойной организации клиент-серверных приложений. В этой модели традиционно выделяются три слоя: слой внешнего интерфейса, слой прикладной логики и слой доступа к данным и/или ресурсам.
Вертикальная декомпозиция выполняется на основе функциональной структуры проектируемого приложения. Реализация каждого прикладного объекта требует включения фрагментов кода в программные модули различных слоев. Будем называть функциональными компонентами совокупность кодовых фрагментов различных слоев, составляющих реализацию этого прикладного объекта.
В частности, в рамках создания системы учета загрузки каналов распределенной информационной сети РГУ было осуществлено следующее разбиение по горизонтальным составляющим:
СПОЙ ЫН CUI Htifti Н Н Г* рф-СН ild
CtpdHHU.bl HTML, СЦ«ШрНМ JdVdMiripL
Спой мрнкл-адний Лtil нкн
ОБыгкТы РНР
ОБыгкгы CQRBA
М П 4ft
Слой дооупл к данный и ресурсди
В задачи слоя внешнего интерфейса входит визуальное оформление данных, предоставленных клиенту. В рассматриваемой системе это осуществляется с помощью языка разметки гипертекста HTML и функций интерпретируемого языка Javascript, используемого для написания сценариев на стороне клиента .
Слой прикладной логики включает в себя логику визуализации данных и логику приложения. Логика визуализации заключает в себе реализацию видимого аспекта функциональной компоненты - один или несколько визуальных объектов, каждый из которых может представлять данные в различных формах. При построении интерфейсной подсистемы к системе учета трафика, проходящего через внешние каналы телекоммуникационных сетей РГУ, для реализации логики построения отчетов и форм для пользователя, была использована технология PHP, позволяющая обрабатывать гипертекст и формировать HTML страницы на сервере перед их отправкой клиенту. Логику функционирования приложения инкапсулируют прикладные объекты, которые представляют данные и функции прикладной логики приложения. Они взаимодействуют с визуальными объектами представлений и извлекают данные из одного или нескольких источников и/или ресурсов. В рамках предложенной реализации серверные объекты среднего звена реализованы на основе технологии CORBA. Они взаимодействуют с визуальными PHP-объектами через брокер объектных запросов (ORB).
Слой доступа к источникам и ресурсам данных содержит модули, инкапсулирующие и абстрагирующие доступ к базе данных и другим ресурсам, контролируемым системой учета загруженности внешних каналов телекоммуникационной сети РГУ. В рассматриваемой системе источником данных является СУБД PostgreSQL, взаимодействие с которой происходит через ODBC-интерфейс, а ресурсами данных являются маршрутизаторы разных типов и агенты сбора информации из сегментов Ethernet.
Рассмотрим вертикальную декомпозицию функциональной компоненты генерации статистических отчетов о загруженности каналов на основе функцио-
нальной структуры приложения. Указанная компонента состоит из фрагментов, относящихся к слоям различных уровней.
Интерфейсный фрагмент содержит в себе HTML-разметку для построения форм, графиков и гистограмм, а также Javascript-функции проверки корректности данных, введенных пользователем в формы. Фрагмент прикладной логики содержит PHP-функции для динамической генерации графических изображений и заполнения гипертекстовых шаблонов данными о загруженности информационных каналов, а также CORBA-объекта, обрабатывающего эти данные и предоставляющего доступ к ним. К фрагменту доступа к источникам и ресурсам данных относится таблица базы данных, в которой хранится статистическая информация об уровне загруженности информационных каналов. В предлагаемой реализации в качестве СУБД используется PostgreSQL. Для обращения к данным фрагмент прикладной логики использует интерфейс ODBC.
Разработки на основе предложенной архитектуры используются при администрировании корпоративной компьютерной сетью Ростовского госуниверсите-та, а также в информационных проектах Южно-Российского регионального центра информатизации высшей школы (ЮГИНФО).
Основным направлением дальнейшей работы будет развитие технологии в направлении создания средств, обеспечивающих использование функциональных компонентов при создании систем управления распределенными ресурсами. Это позволит собирать приложения такого класса на основе готовых программных решений, обладающих необходимыми для таких систем свойствами.
В.В. Булаев, И.Н. Котов, Б.А. Телеснин ВЫБОР СХЕМЫ ДАННЫХ В ОЬТР-ПРИЛОЖЕНИЯХ
При построении СУБД-приложений одним из первых этапов проектирования является выбор схемы данных. Если для ROLAP-приложений характерны схемы «звезда» и «снежинка», то для OLTP-приложений общеприняты нормализованные (обычно разработчики ограничиваются 3 нормальной формой) структуры данных. Однако если постановка задачи требует, например, хранения истории изменения сущностей, то в каждой таблице базы данных предполагается наличие интервалов «времени жизни» объекта. Т акой подход, с одной стороны, усложняет условия фильтрации в запросах, а с другой стороны, первичный ключ сущности должен в себя включать и эти интервалы. Причем при использовании суррогатного первичного ключа, в него входят, как минимум, три поля (например: автоинкремент, дата_начала_жизни, дата_окончания_жизни), а в случаях с естественным первичным ключом его размер за счет «времени жизни» увеличивается еще на два поля.
Для решения таких задач предлагается следующий подход: OLTP-
приложения также строить по схеме «снежинка». Здесь центральным местом является таблица «факта», содержащая ссылки на таблицы «измерений». Время жизни объекта в данной ситуации хранится только в одном месте - таблице факта.
Для примера рассмотрим следующую ситуацию. Измерения: человек, отдел, должность. Таблица факта - назначение человека на работу в таком-то отделе на такой-то должности в данный период времени (рис. 1).
