CC BY
42
вого адаптера всех вариантов ролей, входящих в транзакцию.
Отношения тестов и ролей в транзакции. При
реализации тестового адаптера тест является первичным понятием по отношению к роли, то есть роль реализует некоторые условия или этап выполнения теста. В рамках транзакции отношения тестов и ролей аналогичны.
В процессе конфигурирования основной настройкой транзакции является перечень тестов. Составление перечня тестов в транзакции - начальный этап ее формирования. В одну транзакцию могут быть добавлены только тесты, принадлежащие одному тестовому адаптеру. После завершения этого этапа производится добавление в транзакцию вариантов ролей, которые поддерживают хотя бы один из тестов, включенных в транзакцию ранее. В одну транзакцию могут быть добавлены несколько вариантов одной и той же роли тестового адаптера.
Выполнение тестовых транзакций производится в среде виртуальных машин вариантов ролей, создаваемых исполняющей подсистемой. Поскольку вариант роли может поддерживать не все тесты, входящие в состав транзакции, виртуальная машина варианта роли выполняет только те тесты, которые включены в транзакцию и поддерживаются вариантом роли. При выполнении тестов соблюдается их порядок в транзакции, заданный пользователем.
Если в транзакцию добавлены варианты роли, которые не поддерживают отдельные тесты, входящие в состав транзакции, то в процессе выполнения сеанса тестирования ни один из таких тестов выполняться не может. Транзакция, сконфигурированная подобным образом, считается подготовленной некорректно, и средства ПК «Сервер-Тест» не позволят запустить сеанс тестирования с использованием данной транзакции, пока ошибка не будет исправлена, то есть все тесты в транзакции будут задействованы,
а среди вариантов ролей, поддерживающих данные тесты, будет хотя бы одна ведущая.
В качестве основы исполнения тестов в ПК «Сервер-Тест» используется модель конвейерной обработки тестовых заданий, в которой тесты выполняются поэтапно. Выполнение различных этапов теста (ролей) происходит асинхронно и параллельно на различных станциях в сети. Последовательность выполнения ролей может быть не линейной, а представляющей граф: очередность выполнения ролей зависит от различных настроек и результатов выполнения работы определенной ролью.
Для каждого варианта роли заранее определен список смежных ролей, которым данный вариант роли способен посылать тестовые данные. При отправлении тестовых данных какой-либо роли необходимо соблюдать формат входных данных этой роли.
Реализация асинхронной конвейерной обработки тестовых заданий ПК «Сервер-Тест» предоставляет пользователю гибкие возможности по настройке и диагностике. Варианты ролей, входящие в состав транзакций, могут назначаться на различные группы станций, входящие в полигон испытаний. Средства ПК «Сервер-Тест» выполняют сбор статистической информации о нагрузке экземпляров каждого варианта роли в транзакции, на основе которой вычисляется среднее время ожидания тестовых данных в очередях экземпляров вариантов ролей. Анализ полученной информации позволяет сделать вывод о правильности настроек сеанса тестирования и внести необходимые исправления. Если среднее время ожидания тестовых данных в очередях экземпляров какого-либо варианта роли намного больше, чем у остальных, то необходимо внести изменения в настройки прототипа сеанса тестирования, определив вариант роли на дополнительные группы станций либо в настройки сеанса тестирования, увеличив число пользователей для данного варианта роли.
СТРУКТУРА ПРИЛОЖЕНИЯ ДЛЯ РАБОТЫ С БАЗАМИ ДАННЫХ
Ю.С. Литвинов, В.А. Масюков
Современные инструментальные средства разработки приложений для баз данных (БД) предоставляют широкие возможности для создания программных проектов любой сложности. Однако при этом возникает проблемы, связанные с выбором структуры приложений и рациональных способов их реализации. Важность решения этих проблем возрастает по мере роста объема и сложности проектов. Ошибки выбора структуры, а также методики их реализации приводят к резкому увеличению программного кода, в том числе многократного его дублирования, увеличению сроков разработки, ухудшают возможности сопровождения и модификации приложений, когда изменение, внесенное в один из объектов, может непредсказуемым образом повлиять на работу других объектов.
Для решения этих проблем была разработана, реализована в программных продуктах и исследована пятиуровневая модель организации данных (см. рисунок), предназначенная для построения клиент-серверных систем для работы с реляционными БД, ориентированных на конечного пользователя. Статья посвящена одному из возможных способов реализации данной модели.
Результаты исследований показывают, что любое отклонение от данной схемы отрицательно сказывается на качестве и характеристиках реализуемых приложений. Наиболее сложной оказалась задача выбора способа организации программного обеспечения промежуточного слоя и методики связывания всех уровней в единое целое, без чего схема не может нормально функционировать. Для решения дан-
I IV
а '
I. Структура таблиц БД со сложными связями между ними
II. Хранимые процедуры для реализации доступа к данным и их обработка. Одной таблице может соответствовать
III. Программные объекты для работы с таблицами, обеспечивающие механизмы интеллектуального отбора и изменения данных конечным пользова-
IV. Программный алгоритм приложения, обеспечивающий работу программы, активно использующий программные объекты для работы с БД
множество хра- телем, алгоритмом и нимых процедур другими программными объектами
V. Часть программы, обеспечивающая интерфейс взаимодействия с пользователем и внешней средой, интегрированный с алгоритмом и программными объектами БД
Пятиуровневая структура организации данных при разработке приложений. Объекты каждого уровня могут произвольным образом использовать любые другие объекты, находящиеся на данном уровне (на рисунке не отображено).
V
ной задачи были разработаны специальные саяв-средства и библиотека специализированных программных объектов, которые были проверены на ряде проектов.
Строение и назначение структурных уровней
Структура таблиц БД. Разработка структуры БД производится общепринятыми способами проектирования реляционных БД.
Для обеспечения правильной работы средств автоматизации проектирования и для создания единого пространства имен были введены специальные правила именования объектов. На использование специальных объектов БД (генераторы, триггеры, функции и др.) никаких ограничений не накладывается.
Для целей ведения реализации прав доступа на уровне записей в конкретных проектах были введены дополнительные поля и разработана технология организации средств поддержки.
Хранимые процедуры для реализации доступа к данным и их обработка. Доступ к информации, содержащейся в таблицах БД, осуществляется не непосредственно, а через хранимые процедуры. Все действия конечного пользователя над таблицами можно подразделить на две категории:
- стандартные - отбор и упорядочивание данных в соответствии с заданными критериями, вставка, удаление и модификация записей;
- специальные - любые другие действия над наборами данных.
Данные категории не являются равноценными, практика показывает, что наибольший объем приходится на 1 категорию (примерное соотношение 90% к 10%), это означает, что автоматизация процесса проектирования стандартных действий приводит к ощутимому выигрышу в процессе разработки и эксплуатации системы в целом. Для этих целей был выработан специальный формат хранимых процедур, обеспечивающих стандартные действия, и реализовано саяв-средство для их автоматической генерации.
Использование хранимых процедур гарантирует работоспособность расширенной техники управления правами доступа, а также обеспечивает многочисленные преимущества, связанные с переносом центра обработки информации с клиентского приложения на сервер.
Использование стандартов в оформлении процедур, а также специализированных вспомогательных средств позволяет обеспечить их легкую интеграцию со следующими уровнями.
Программные объекты для работы с таблицами. Хранимые процедуры располагаются непосредственно в БД на сервере, в то время как доступ к их возможностям и результату работы осуществляется в приложении на компьютере клиента. Кроме того, для работы с объектами «Таблица» и «Хранимая процедура» сервер предполагает использование специализированного языка (SQL), а для обеспечения комфортной работы конечного пользователя предоставляются стандартные визуальные средства манипулирования данными.
• Отображение набора данных в соответствии с заданным набором входных параметров в таблице или в другом виде, отвечающем условию задачи.
• Возможности редактирования данных и обеспечения контроля ввода и корректной отработки возможных исключительных ситуаций, в том числе обеспечение вызова других программных объектов для редактирования ссылочных полей.
• Сортировка данных по любому заданному полю или их комбинации.
• Фильтрация данных или их поиск по условию, задаваемому пользователем.
• Возможность изменения порядка расположения полей и их размеров, цветовой гаммы в зависимости от предпочтений пользователя или возможностей экрана монитора.
• Сохранение визуального и параметрического составов объекта между сеансами в связи с предпочтениями конкретного пользователя.
• Полноценная возможность использования режимов ручного ввода и с помощью мыши.
• Контроль за ограничениями прав доступа не только на уровне таблиц и хранимых процедур, что обеспечивается стандартными средствами СУБД, но и на уровне записей (например, один пользователь может не иметь возможность редактирования записи, созданной другим пользователем, но это может сделать его непосредственный начальник, о чем останется соответствующий след).
• Обеспечение независимости (!) программного объекта от изменения структуры данных таблицы.
Реализация всех пунктов, кроме последнего, не требует специального программирования и осуществляется при помощи разработанной технологии создания программных объектов.
Центральным звеном модели, обеспечивающим ее работоспособность, является сже-средство для генерации файла определений программных объектов. Основой для формирования этого файла служат стандартные хранимые процедуры, которые однозначно задают входные и выходные параметры, что обеспечивается соглашениями на правила их формирования и использования пространства имен.
Техника создания объектов и организации работы с параметрами с использованием файла определений практически исключает возможность появления критических для работы ошибок и обеспечивает легкое реструктурирование объектов в полной согласованности с изменениями структуры БД. Помимо всего прочего, специализированная программная библиотека содержит все необходимые средства для быстрого создания объектов.
Программный алгоритм приложения. Программные объекты многое умеют делать с таблицами БД, но они являются только основным ядром программы приложения, его основной библиотекой. Кроме них, приложения могут содержать пользовательские алгоритмы и составные объекты, состоящие из набора объектов, входящих в библиотеку. Разные приложения могут содержать разные комбинации модифицированных алгоритмов и составных объектов. В этом смысле следует вести речь о повторном использовании ранее созданных объектов в рамках приложения и о возможности внесения изменения в логику их работы и в форму внешнего представления в контексте конкретной задачи. Для случая интеграции объектов были решены следующие задачи.
• Размещение без дополнительного программирования на одной форме различных объектов и организация их совместной работы.
• Изменение внешнего вида объектов с целью соответствия новым условиям.
• Обеспечение всей функциональной полноты оригинальных объектов, то есть полный набор команд и стандартных средств манипулирования данными.
• Обеспечение рассылки и обработки сообщений между независимыми объектами. С этой целью были разработаны две методики:
1) методика встраивания объектов, когда объект становится составной частью другого, при этом настройка внешних атрибутов (размер, цвет, видимость и др.) для каждого составного объекта производится с помощью вспомогательных ресурсных файлов.
2) методика косвенного вызова, которая применяется для случаев сильного изменения внешнего вида объекта по сравнению с объектом-оригиналом. Для этого на форме располагают необходимые элементы управления и отображения, а затем осуществляется их связывание с соответствующими им по функциональному назначению полями оригинального объекта. Все действия, производимые в фокусе
связанных объектов (нажатие клавиш, движение мыши и щелчки ее кнопок), передаются в поля оригинала и там обрабатываются, а из них возвращается результат работы.
Составные объекты, в свою очередь, могут быть размещены в общей библиотеке и использованы в составе других объектов. Уровень использования одними объектами других ничем не ограничивается. Данный структурный уровень является своеобразным клеем для соединения всех необходимых программных объектов и алгоритмов в единое целое.
Интерфейс взаимодействия с пользователем и внешней средой. Создание модели этого уровня осуществлено на основе организации мета-среды, содержащей информацию, которая является доступной для каждого объекта и учитывается при их работе. Кроме того, мета-среда содержит информацию для обеспечения работоспособности приложения в целом, например, для обеспечения решения задач администрирования.
Как видно из рисунка, объекты работающего приложения могут составлять не единое целое, а представлять собой распределенный набор. Таким образом, для обеспечения их правильного функционирования надо точно знать месторасположение объектов и методику доступа к ним.
Пользовательское приложение, в свою очередь, также является программным объектом и должно обеспечивать взаимодействие с другими программными комплексами, расположенными в вычислительной сети, или интегрировать в себе их возможности (например, встраивать внешние приложения в виде подключаемых модулей).
Опыт использования программного обеспечения, созданного в соответствии с рассмотренной пятиуровневой моделью организации данных при разработке приложений, подтверждает достижение следующих результатов.
• Резкое сокращение сроков разработки.
• Резкое сокращение объема программного кода (в разы!) без потери его функциональности.
• Возможность автоматизации процесса проектирования, реализации и модификации программного обеспечения как на стороне сервера, так и на стороне клиента.
• Обеспечение свойств самодокументированно-сти программного кода.
• Повторное использование объектов и их копий, в том числе с измененными свойствами и формой отображения.
• Создание «синтетических» сборных объектов из набора независимых объектов с обеспечением их синхронной работы.
• Автоматическая реконфигурация программных объектов адекватно изменению структуры данных, в том числе изменению числа параметров объектов любого уровня и их типа.
• Достижение высокой стандартности кода и доступности сторонним разработчикам.
• Возможность создавать распределенные приложения.
Кроме того, опыт эксплуатации разработанного программного обеспечения показывает, что оно мо-
жет быть легко освоено программистами средней квалификации.
РОЛЬ И МЕСТО СИСТЕМ ЗАЩИТЫ ИНФОРМАЦИИ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ
Ю.И. Арепин, В.В. Карпов
Достижения последних лет в области компьютерных и информационных технологий обусловили возможность создания автоматизированных систем (АС) обработки информации в целом ряде областей человеческой деятельности, еще недавно практически не охваченных процессами автоматизации.
В частности, с развитием средств и методов распределенной обработки данных, создание АС организационного управления стало одним из основных направлений повышения эффективности решения задач, характеризующихся сжатыми сроками выполнения и нечеткостью формального описания.
Указанная тенденция особенно актуальна для организаций, служб и штабов министерства обороны (МО), претерпевающих в ходе военной реформы сокращение личного состава при сохранении перечня стоящих перед этими организациями задач.
Сущность и основные положения автоматизации организационного управления [1], реализуемые в современных АС, предполагают разработку и поддержку в составе АС средств обеспечения безопасности информации. При этом показатель информационной безопасности становится одной из основных характеристик информационных систем, в особенности систем военного назначения [2].
Значение систем защиты информации (СЗИ) для АС подчеркивается и тем фактом, что в большинстве развитых стран деятельность в этой области лицензируется, а разработанные изделия подлежат сертификации.
В нашей стране основными руководящими документами (РД), регламентирующими создание защищенных АС, являются РД Гостехкомиссии (ГТК) России, содержащие в основе своей концепцию защиты средств вычислительной техники (СВТ) и АС от несанкционированного доступа (НСД) к информации.
Очевидная направленность концепции в основном на решение вопросов обеспечения защиты компьютерных систем от НСД неоднократно комментировалась и критиковалась [4]. Современные подходы к защите информации требуют обеспечения как минимум трех свойств информации в защищаемой системе: конфиденциальности, целостности, доступности.
Однако уклон разработчиков РД ГТК в сторону обеспечения защиты информации от НСД объясняется, по-видимому, тем фактом, что документы были разработаны в расчете на применение преимущественно в информационных системах силовых струк-
тур, в частности, МО. При этом, вероятно, предполагалось, что незакрытый и нераспознанный канал утечки информации из АС специального назначения способен принести гораздо больше ущерба, чем потеря целостности или доступа, восстановление которых в АС, как правило, достаточно отработано.
В РД ГТК дается понятие НСД как доступа к информации, нарушающего установленные правила разграничения доступа, с использованием штатных средств, предоставляемых СВТ или АС.
К основным способам НСД относятся:
- непосредственное обращение к объектам доступа;
- создание программных и технических средств, выполняющих обращение к объектам доступа в обход средств защиты;
- модификация средств защиты, позволяющая осуществить НСД;
- внедрение в технические средства СВТ программных или технических механизмов, нарушающих предполагаемую структуру и функции СВТ или АС и позволяющих осуществить НСД.
РД ГТК определяют семь принципов защиты информации:
- защита СВТ и АС основывается на положениях и требованиях существующих законов, стандартов и нормативно-методических документов по защите от НСД к информации;
- защита СВТ обеспечивается комплексом программно-технических средств;
- защита АС обеспечивается комплексом программно-технических средств и поддерживающих их организационных мер;
- защита АС должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ;
- программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики АС;
- неотъемлемой частью работ по защите является оценка эффективности средств защиты, осуществляемая по методике, учитывающей всю совокупность технических характеристик оцениваемого объекта, включая технические решения и практическую реализацию средств защиты;
- защита АС должна предусматривать контроль эффективности средств защиты от НСД, который либо может быть периодическим, либо иницииро-
