Структура приложения для работы с базами данных

вого адаптера всех вариантов ролей, входящих в транзакцию.

Отношения тестов и ролей в транзакции. При

реализации тестового адаптера тест является первичным понятием по отношению к роли, то есть роль реализует некоторые условия или этап выполнения теста. В рамках транзакции отношения тестов и ролей аналогичны.

В процессе конфигурирования основной настройкой транзакции является перечень тестов. Составление перечня тестов в транзакции - начальный этап ее формирования. В одну транзакцию могут быть добавлены только тесты, принадлежащие одному тестовому адаптеру. После завершения этого этапа производится добавление в транзакцию вариантов ролей, которые поддерживают хотя бы один из тестов, включенных в транзакцию ранее. В одну транзакцию могут быть добавлены несколько вариантов одной и той же роли тестового адаптера.

Выполнение тестовых транзакций производится в среде виртуальных машин вариантов ролей, создаваемых исполняющей подсистемой. Поскольку вариант роли может поддерживать не все тесты, входящие в состав транзакции, виртуальная машина варианта роли выполняет только те тесты, которые включены в транзакцию и поддерживаются вариантом роли. При выполнении тестов соблюдается их порядок в транзакции, заданный пользователем.

Если в транзакцию добавлены варианты роли, которые не поддерживают отдельные тесты, входящие в состав транзакции, то в процессе выполнения сеанса тестирования ни один из таких тестов выполняться не может. Транзакция, сконфигурированная подобным образом, считается подготовленной некорректно, и средства ПК «Сервер-Тест» не позволят запустить сеанс тестирования с использованием данной транзакции, пока ошибка не будет исправлена, то есть все тесты в транзакции будут задействованы,

а среди вариантов ролей, поддерживающих данные тесты, будет хотя бы одна ведущая.

В качестве основы исполнения тестов в ПК «Сервер-Тест» используется модель конвейерной обработки тестовых заданий, в которой тесты выполняются поэтапно. Выполнение различных этапов теста (ролей) происходит асинхронно и параллельно на различных станциях в сети. Последовательность выполнения ролей может быть не линейной, а представляющей граф: очередность выполнения ролей зависит от различных настроек и результатов выполнения работы определенной ролью.

Для каждого варианта роли заранее определен список смежных ролей, которым данный вариант роли способен посылать тестовые данные. При отправлении тестовых данных какой-либо роли необходимо соблюдать формат входных данных этой роли.

Реализация асинхронной конвейерной обработки тестовых заданий ПК «Сервер-Тест» предоставляет пользователю гибкие возможности по настройке и диагностике. Варианты ролей, входящие в состав транзакций, могут назначаться на различные группы станций, входящие в полигон испытаний. Средства ПК «Сервер-Тест» выполняют сбор статистической информации о нагрузке экземпляров каждого варианта роли в транзакции, на основе которой вычисляется среднее время ожидания тестовых данных в очередях экземпляров вариантов ролей. Анализ полученной информации позволяет сделать вывод о правильности настроек сеанса тестирования и внести необходимые исправления. Если среднее время ожидания тестовых данных в очередях экземпляров какого-либо варианта роли намного больше, чем у остальных, то необходимо внести изменения в настройки прототипа сеанса тестирования, определив вариант роли на дополнительные группы станций либо в настройки сеанса тестирования, увеличив число пользователей для данного варианта роли.

СТРУКТУРА ПРИЛОЖЕНИЯ ДЛЯ РАБОТЫ С БАЗАМИ ДАННЫХ

Ю.С. Литвинов, В.А. Масюков

Современные инструментальные средства разработки приложений для баз данных (БД) предоставляют широкие возможности для создания программных проектов любой сложности. Однако при этом возникает проблемы, связанные с выбором структуры приложений и рациональных способов их реализации. Важность решения этих проблем возрастает по мере роста объема и сложности проектов. Ошибки выбора структуры, а также методики их реализации приводят к резкому увеличению программного кода, в том числе многократного его дублирования, увеличению сроков разработки, ухудшают возможности сопровождения и модификации приложений, когда изменение, внесенное в один из объектов, может непредсказуемым образом повлиять на работу других объектов.

Для решения этих проблем была разработана, реализована в программных продуктах и исследована пятиуровневая модель организации данных (см. рисунок), предназначенная для построения клиент-серверных систем для работы с реляционными БД, ориентированных на конечного пользователя. Статья посвящена одному из возможных способов реализации данной модели.

Результаты исследований показывают, что любое отклонение от данной схемы отрицательно сказывается на качестве и характеристиках реализуемых приложений. Наиболее сложной оказалась задача выбора способа организации программного обеспечения промежуточного слоя и методики связывания всех уровней в единое целое, без чего схема не может нормально функционировать. Для решения дан-

I IV

а '

I. Структура таблиц БД со сложными связями между ними

II. Хранимые процедуры для реализации доступа к данным и их обработка. Одной таблице может соответствовать

III. Программные объекты для работы с таблицами, обеспечивающие механизмы интеллектуального отбора и изменения данных конечным пользова-

IV. Программный алгоритм приложения, обеспечивающий работу программы, активно использующий программные объекты для работы с БД

множество хра- телем, алгоритмом и нимых процедур другими программными объектами

V. Часть программы, обеспечивающая интерфейс взаимодействия с пользователем и внешней средой, интегрированный с алгоритмом и программными объектами БД

Пятиуровневая структура организации данных при разработке приложений. Объекты каждого уровня могут произвольным образом использовать любые другие объекты, находящиеся на данном уровне (на рисунке не отображено).

V

ной задачи были разработаны специальные саяв-средства и библиотека специализированных программных объектов, которые были проверены на ряде проектов.

Строение и назначение структурных уровней

Структура таблиц БД. Разработка структуры БД производится общепринятыми способами проектирования реляционных БД.

Для обеспечения правильной работы средств автоматизации проектирования и для создания единого пространства имен были введены специальные правила именования объектов. На использование специальных объектов БД (генераторы, триггеры, функции и др.) никаких ограничений не накладывается.

Для целей ведения реализации прав доступа на уровне записей в конкретных проектах были введены дополнительные поля и разработана технология организации средств поддержки.

Хранимые процедуры для реализации доступа к данным и их обработка. Доступ к информации, содержащейся в таблицах БД, осуществляется не непосредственно, а через хранимые процедуры. Все действия конечного пользователя над таблицами можно подразделить на две категории:

- стандартные - отбор и упорядочивание данных в соответствии с заданными критериями, вставка, удаление и модификация записей;

- специальные - любые другие действия над наборами данных.

Данные категории не являются равноценными, практика показывает, что наибольший объем приходится на 1 категорию (примерное соотношение 90% к 10%), это означает, что автоматизация процесса проектирования стандартных действий приводит к ощутимому выигрышу в процессе разработки и эксплуатации системы в целом. Для этих целей был выработан специальный формат хранимых процедур, обеспечивающих стандартные действия, и реализовано саяв-средство для их автоматической генерации.

Использование хранимых процедур гарантирует работоспособность расширенной техники управления правами доступа, а также обеспечивает многочисленные преимущества, связанные с переносом центра обработки информации с клиентского приложения на сервер.

Использование стандартов в оформлении процедур, а также специализированных вспомогательных средств позволяет обеспечить их легкую интеграцию со следующими уровнями.

Программные объекты для работы с таблицами. Хранимые процедуры располагаются непосредственно в БД на сервере, в то время как доступ к их возможностям и результату работы осуществляется в приложении на компьютере клиента. Кроме того, для работы с объектами «Таблица» и «Хранимая процедура» сервер предполагает использование специализированного языка (SQL), а для обеспечения комфортной работы конечного пользователя предоставляются стандартные визуальные средства манипулирования данными.

• Отображение набора данных в соответствии с заданным набором входных параметров в таблице или в другом виде, отвечающем условию задачи.

• Возможности редактирования данных и обеспечения контроля ввода и корректной отработки возможных исключительных ситуаций, в том числе обеспечение вызова других программных объектов для редактирования ссылочных полей.

• Сортировка данных по любому заданному полю или их комбинации.

• Фильтрация данных или их поиск по условию, задаваемому пользователем.

• Возможность изменения порядка расположения полей и их размеров, цветовой гаммы в зависимости от предпочтений пользователя или возможностей экрана монитора.

• Сохранение визуального и параметрического составов объекта между сеансами в связи с предпочтениями конкретного пользователя.

• Полноценная возможность использования режимов ручного ввода и с помощью мыши.

• Контроль за ограничениями прав доступа не только на уровне таблиц и хранимых процедур, что обеспечивается стандартными средствами СУБД, но и на уровне записей (например, один пользователь может не иметь возможность редактирования записи, созданной другим пользователем, но это может сделать его непосредственный начальник, о чем останется соответствующий след).

• Обеспечение независимости (!) программного объекта от изменения структуры данных таблицы.

Реализация всех пунктов, кроме последнего, не требует специального программирования и осуществляется при помощи разработанной технологии создания программных объектов.

Центральным звеном модели, обеспечивающим ее работоспособность, является сже-средство для генерации файла определений программных объектов. Основой для формирования этого файла служат стандартные хранимые процедуры, которые однозначно задают входные и выходные параметры, что обеспечивается соглашениями на правила их формирования и использования пространства имен.

Техника создания объектов и организации работы с параметрами с использованием файла определений практически исключает возможность появления критических для работы ошибок и обеспечивает легкое реструктурирование объектов в полной согласованности с изменениями структуры БД. Помимо всего прочего, специализированная программная библиотека содержит все необходимые средства для быстрого создания объектов.

Программный алгоритм приложения. Программные объекты многое умеют делать с таблицами БД, но они являются только основным ядром программы приложения, его основной библиотекой. Кроме них, приложения могут содержать пользовательские алгоритмы и составные объекты, состоящие из набора объектов, входящих в библиотеку. Разные приложения могут содержать разные комбинации модифицированных алгоритмов и составных объектов. В этом смысле следует вести речь о повторном использовании ранее созданных объектов в рамках приложения и о возможности внесения изменения в логику их работы и в форму внешнего представления в контексте конкретной задачи. Для случая интеграции объектов были решены следующие задачи.

• Размещение без дополнительного программирования на одной форме различных объектов и организация их совместной работы.

• Изменение внешнего вида объектов с целью соответствия новым условиям.

• Обеспечение всей функциональной полноты оригинальных объектов, то есть полный набор команд и стандартных средств манипулирования данными.

• Обеспечение рассылки и обработки сообщений между независимыми объектами. С этой целью были разработаны две методики:

1) методика встраивания объектов, когда объект становится составной частью другого, при этом настройка внешних атрибутов (размер, цвет, видимость и др.) для каждого составного объекта производится с помощью вспомогательных ресурсных файлов.

2) методика косвенного вызова, которая применяется для случаев сильного изменения внешнего вида объекта по сравнению с объектом-оригиналом. Для этого на форме располагают необходимые элементы управления и отображения, а затем осуществляется их связывание с соответствующими им по функциональному назначению полями оригинального объекта. Все действия, производимые в фокусе

связанных объектов (нажатие клавиш, движение мыши и щелчки ее кнопок), передаются в поля оригинала и там обрабатываются, а из них возвращается результат работы.

Составные объекты, в свою очередь, могут быть размещены в общей библиотеке и использованы в составе других объектов. Уровень использования одними объектами других ничем не ограничивается. Данный структурный уровень является своеобразным клеем для соединения всех необходимых программных объектов и алгоритмов в единое целое.

Интерфейс взаимодействия с пользователем и внешней средой. Создание модели этого уровня осуществлено на основе организации мета-среды, содержащей информацию, которая является доступной для каждого объекта и учитывается при их работе. Кроме того, мета-среда содержит информацию для обеспечения работоспособности приложения в целом, например, для обеспечения решения задач администрирования.

Как видно из рисунка, объекты работающего приложения могут составлять не единое целое, а представлять собой распределенный набор. Таким образом, для обеспечения их правильного функционирования надо точно знать месторасположение объектов и методику доступа к ним.

Пользовательское приложение, в свою очередь, также является программным объектом и должно обеспечивать взаимодействие с другими программными комплексами, расположенными в вычислительной сети, или интегрировать в себе их возможности (например, встраивать внешние приложения в виде подключаемых модулей).

Опыт использования программного обеспечения, созданного в соответствии с рассмотренной пятиуровневой моделью организации данных при разработке приложений, подтверждает достижение следующих результатов.

• Резкое сокращение сроков разработки.

• Резкое сокращение объема программного кода (в разы!) без потери его функциональности.

• Возможность автоматизации процесса проектирования, реализации и модификации программного обеспечения как на стороне сервера, так и на стороне клиента.

• Обеспечение свойств самодокументированно-сти программного кода.

• Повторное использование объектов и их копий, в том числе с измененными свойствами и формой отображения.

• Создание «синтетических» сборных объектов из набора независимых объектов с обеспечением их синхронной работы.

• Автоматическая реконфигурация программных объектов адекватно изменению структуры данных, в том числе изменению числа параметров объектов любого уровня и их типа.

• Достижение высокой стандартности кода и доступности сторонним разработчикам.

• Возможность создавать распределенные приложения.

Кроме того, опыт эксплуатации разработанного программного обеспечения показывает, что оно мо-

жет быть легко освоено программистами средней квалификации.

РОЛЬ И МЕСТО СИСТЕМ ЗАЩИТЫ ИНФОРМАЦИИ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ

Ю.И. Арепин, В.В. Карпов

Достижения последних лет в области компьютерных и информационных технологий обусловили возможность создания автоматизированных систем (АС) обработки информации в целом ряде областей человеческой деятельности, еще недавно практически не охваченных процессами автоматизации.

В частности, с развитием средств и методов распределенной обработки данных, создание АС организационного управления стало одним из основных направлений повышения эффективности решения задач, характеризующихся сжатыми сроками выполнения и нечеткостью формального описания.

Указанная тенденция особенно актуальна для организаций, служб и штабов министерства обороны (МО), претерпевающих в ходе военной реформы сокращение личного состава при сохранении перечня стоящих перед этими организациями задач.

Сущность и основные положения автоматизации организационного управления [1], реализуемые в современных АС, предполагают разработку и поддержку в составе АС средств обеспечения безопасности информации. При этом показатель информационной безопасности становится одной из основных характеристик информационных систем, в особенности систем военного назначения [2].

Значение систем защиты информации (СЗИ) для АС подчеркивается и тем фактом, что в большинстве развитых стран деятельность в этой области лицензируется, а разработанные изделия подлежат сертификации.

В нашей стране основными руководящими документами (РД), регламентирующими создание защищенных АС, являются РД Гостехкомиссии (ГТК) России, содержащие в основе своей концепцию защиты средств вычислительной техники (СВТ) и АС от несанкционированного доступа (НСД) к информации.

Очевидная направленность концепции в основном на решение вопросов обеспечения защиты компьютерных систем от НСД неоднократно комментировалась и критиковалась [4]. Современные подходы к защите информации требуют обеспечения как минимум трех свойств информации в защищаемой системе: конфиденциальности, целостности, доступности.

Однако уклон разработчиков РД ГТК в сторону обеспечения защиты информации от НСД объясняется, по-видимому, тем фактом, что документы были разработаны в расчете на применение преимущественно в информационных системах силовых струк-

тур, в частности, МО. При этом, вероятно, предполагалось, что незакрытый и нераспознанный канал утечки информации из АС специального назначения способен принести гораздо больше ущерба, чем потеря целостности или доступа, восстановление которых в АС, как правило, достаточно отработано.

В РД ГТК дается понятие НСД как доступа к информации, нарушающего установленные правила разграничения доступа, с использованием штатных средств, предоставляемых СВТ или АС.

К основным способам НСД относятся:

- непосредственное обращение к объектам доступа;

- создание программных и технических средств, выполняющих обращение к объектам доступа в обход средств защиты;

- модификация средств защиты, позволяющая осуществить НСД;

- внедрение в технические средства СВТ программных или технических механизмов, нарушающих предполагаемую структуру и функции СВТ или АС и позволяющих осуществить НСД.

РД ГТК определяют семь принципов защиты информации:

- защита СВТ и АС основывается на положениях и требованиях существующих законов, стандартов и нормативно-методических документов по защите от НСД к информации;

- защита СВТ обеспечивается комплексом программно-технических средств;

- защита АС обеспечивается комплексом программно-технических средств и поддерживающих их организационных мер;

- защита АС должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ;

- программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики АС;

- неотъемлемой частью работ по защите является оценка эффективности средств защиты, осуществляемая по методике, учитывающей всю совокупность технических характеристик оцениваемого объекта, включая технические решения и практическую реализацию средств защиты;

- защита АС должна предусматривать контроль эффективности средств защиты от НСД, который либо может быть периодическим, либо иницииро-