Применение метаданных в адаптивных информационных системах клиент-серверной архитектуры Текст научной статьи по специальности «Компьютерные и информационные науки»

Шибанов С.В. , Мезенков А.А., Макарычев П.П. ПРИМЕНЕНИЕ МЕТАДАННЫХ В АДАПТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ

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

Введение

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

В предметных областях, которые постоянно развиваются, возникает потребность в адаптивных информационных системах.

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

Требования и технологии к адаптации информационных систем

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

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

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

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

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

- Адекватно отражать знания о предметной области в каждый момент времени.

- Быть пригодными для лёгкой и быстрой реконструкции при изменении предметной области.

Адаптивные свойства информационных систем обеспечиваются за счёт интеллектуализации их архитектуры. Ядром таких систем является постоянно развиваемая модель предметной области, поддерживаемая в специальной базе знаний - репозитории. Ядро системы управляет процессами генерации или переконфигурирования программного обеспечения. Таким образом, проектирование и адаптация ИС сводится, прежде всего, к построению модели проблемной области и ее своевременной корректировке [1].

При проектировании информационной системы обычно используются два подхода: оригинальное или

типовое проектирование. Первый подход предполагает разработку информационной системы "с чистого листа" в соответствии с требованиями экономического объекта, второй подход - адаптацию типовых разработок к особенностям экономического объекта. Первый подход, как правило, реализуется на основе применения систем автоматизированного проектирования информационных систем или CASE-технологий, например, таких как, SilverRun (SilverRun Technology), Natural LightStorm (Software AG) и др., второй подход - на основе применения систем компонентного проектирования информационных систем, например, таких как R/3 (SAP), BAAN IV (Baan Corp), Prodis (Software AG), Галактика (Новый Атлант) и др [1].

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

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

Таким образом, при разработке адаптивной информационной системы возникает следующий ряд проблем:

1) разработка структуры и модели метаданных для адаптации, а также специальной базы знаний (репозитория) для хранения их;

2) создание технологий адаптивного пользовательского интерфейса, которые включают:

а) коррекция ошибок пользователя при работе с системой;

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

в) изменение уровня сложности интерфейса в соответствии с характеристиками пользователя;

г) адаптация к интенсивности информационного обмена между пользователем и системой;

д) адаптация технической системы к целям и намерениям пользователя;

е) выбор оптимальных для пользователя форм и последовательностей представления информационных ресурсов;

ж) адаптация к аппаратно-программному окружению.

3) реализация механизма взаимодействия репозитория с информационной системой.

Моделирование метаданных для адаптации важно, поскольку оно может стать элементом, который используется во всей информационной системе. Существует несколько способов выбора модели метаданных:

- создание специальной модели данных для работы с метаданными;

- использование имеющихся стандартных моделей;

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

Модели метаданных и способы их реализации в адаптивных информационных системах

Для создания специальной модели метаданных важно иметь корректные определения элементов, их атрибутов и связей с другими элементами. Такая модель может быть объектно-ориентированной или моделью типа объект-отношение. Что касается стандартных моделей, то тут существует два варианта: модель открытой информации (Open Information Model, сокр. OIM) и общая метамодель Хранилища данных (Common Warehouse Meta-Model, сокр. CWM) . CWM описывает обмен метаданными между Хранилищами данных, средствами Business Intelligence и управления знаниями и портальными технологиями. OIM -это набор спецификаций метаданных для облегчения их совместного и многократного использования в области разработки приложений и Хранилищ данных. OIM описывается с помощью универсального языка моделирования (Unified Modeling Language, сокр. UML) и организуется по предметным областям, которые могут быть легко использованы и при необходимости расширены. Эта модель данных основана на отраслевых стандартах, таких как UML, XML и SQL.

После завершения моделирования метаданных для адаптации важно определить репозиторий для хранения данных. Это может быть реляционное или объектно-ориентированное Хранилище.

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

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

- сравнительно простая поддержка метаданных;

- упрощенные процедуры взаимодействия между компонентами;

- простые процедуры подготовки отчетности.

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

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

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

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

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

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

При разработке АИС «Прокуратура-Статистика» версии 2.0 возникла проблема контроля прав между подразделениями и пользователями системы, также необходимо было хранить индивидуальные настройки каждого пользователя, поэтому было веделено несколько основных объектов предметной области, а именно: тип подразделения (TypeArea), подразделение (Area), форма статистической отчётности

(Form), пользователи (User), отчёт (Report). В совокупности данный набор объектов можно представить в виде графа изображенного на рисунке 1:

Рис 1. Граф объектов предметной области.

У каждого объекта существует свой набор индивидуальных метаданных, к примеру, у пользователя содержится информация о виде пользовательского интерфейса (xml-шаблоны форм, выбранные шрифты и цвета для интерфейса), в TypeArea находятся данные о правах у текущего типа подразделения. Использование графовой модели позволяет организовать механизм наследования, так например при создании пользователем отчёта происходит запрос о доступа к данной форме у объекта Form, запрос на существования данной формы у текущего подразделения у объекта Area, и осуществляется проверка прав на создание отчёта у TypeArea. Так же при печати отчёта запрашиваются данные, о создавшем подразделении у Area, и информация о пользователе. Данный подход позволяет не хранить всю информацию об отчёте в объекте Report, тем самым избежав избыточности данных. Метаданные связанные с адаптацией к аппаратно-программному окружению в АИС «Прокуратура-Статистика» хранятся на каждом отдельном компьютере в виде файлов.

Проблемы адаптации пользовательского интерфейса и способы их решения

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

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

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

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

Однако системы с адаптивным интерфейсами могут вызвать у пользователя чувство потери контроля, возможны некоторые неточности в предсказании желаний и поведения пользователя, что может вызвать эффект «враждебности» со стороны пользователя.

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

Необходимость выбора и отображения той или иной панели инструментов может определяться по совокупности переменных, которые определяют такое понятие как «важность панели инструментов».

«Важность панели инструментов» используется для того, чтобы определять, какая панель будет скрыта из рабочей области зоны наблюдения пользователя. Если максимально допустимое ограничение на отображение панели достигло предела, и возникла необходимость в отображении новой, тогда необходимо освободить пространство для новой панели. Важность панели может выражаться как [5]:

ВП = К1(Тс) + К2(Тп.в.) + К3(Чв), (1)

где Тс - время отображения панели; К1, К2, КЗ - коэффициенты важности панелей.

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

где ^ек - текущее время; tвзаим - время, когда произошло последнее взаимодействие с адаптивной панелью.

Чв - частота взаимодействия. Показывает, как часто используется панель:

^тек ^соз ( 3 )

где N - число взаимодействий с панелью со времени ее создания; ^ек - текущее системное время; ^оз - время создания панели.

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

измеряемых параметрах.

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

Если каждому пользователю системы соответствует своя модель, отличная от других моделей пользователей, то такой подход является индивидуальным. При стереотипном подходе, наоборот, используется предполагаемая принадлежность пользователя к определенной модели (классу), количество которых строго ограниченно. Обычно создают несколько моделей пользователей. И. Бомон выделяет 3 модели: «модель новичка», «модель продвинутого пользователя» и «модель эксперта». При индивидуальном подходе заранее известно, какая модель будет сформирована для конкретного пользователя. После сформирования модели пользователя происходит подстройка интерфейса системы под конкретную модель.

Эффективность работы информационной системы зависит от уровня подготовки пользователя, так как каждый пользователь должен обладать знанием о том:

- какая информация необходима для решения текущей задач;

- какой объем необходимой информации доступен в настоящее время;

- как найти текущую информацию.

Пользователь должен обладать некоторой «моделью» информационной системы, т.е. некоторыми знаниями о ее внутренней структуре.

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

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

- нужно реализовать возможность отключения данного окна;

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

- все функции повторяют пункты в меню и панелей инструментов;

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

- при стремлении разработать приложение с полной адаптацией, требуется реализовать механизмы

сортировки списка функций по следующим критериям: значимости операции, вероятности использования,

частота применения [4].

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

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

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

- настроить параметры интерфейса в соответствии с индивидуальными особенностями пользователя;

- выбрать оптимальную для конкретного пользователя форму и последовательность представления сообщений;

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

- учесть, что пользователь знает или не знает о текущей ситуации, и избежать избыточности или неясности в ответах и объяснениях.

Иногда требуется разрабатывать приложения, в которых пользователю необходимо предоставлять информацию в табличной форме с сложными заголовочными строками и столбцами, а также давать возможность редактировать данные. Внешний вид таблицы можно описать, используя xml. Такой подход обеспечивает автоматизацию создания, отображения и обработки соответствующей таблицы в пользовательском приложении. Он позволяет быстро, практически без внесения изменений в приложения, добавлять новые таблицы и модифицировать структуру существующих таблиц. В xml-схемах, описывающих статистические таблицы, содержатся тэги, определяющие внешний вид (макет) таблиц. Речь идет об описании заголовочных ячеек для столбцов и строк, для которых задаются размеры, нумерация, текст, стиль начертания, ориентация и параметры выравнивания текста. Для внутренних ячеек таблицы, в которых непосредственно размещаются статистические сведения, определяются различные свойства, а именно: формат ячейки (целый, десятичный и т.д.), уровень доступа (доступны или недоступны для редактирования) [6]. Так же необходимо учитывать индивидуальную адаптацию представления информации для пользователя и адаптацию к аппаратно-программному окружению. Данная проблема появилась при разработке АИС «Прокуратура-Статистика» версии 2.0. Хранение структуры форм статистической отчётности производится в xml-шаблонах, для каждой таблицы существует отдельный xml-файл.

Режим: [^Редактирование Блокировка: О Только чтение Права: Редактирование

Рис 2. Главное окно программы с активной функциональной панелью.

Для отображения форм статистической отчётности в клиентском приложении АИС «Прокуратура-Статистика» была разработана система классов в виде компонента ExDataGridView. Диаграмма классов представлена на рисунке 3.

Гибкая настройка отображения форм статистической отчётности, так же включает автоматический подбор оптимального размера формы в главном окне приложения. Это реализуется благодаря

разработанному методу checkWriteText, который осуществляет проверку на вывод текста, с

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

Так как «Прокуратура-Статистика» версии 2.0 многопользовательская автоматизированная система, и каждый пользователь настраивает под себя отображение форм статистической отчётности, был разработан механизм сохранение индивидуальных настроек отображения в базе данных в качестве метаданных для адаптации. Сохранение настроек отображения определённой таблицы осуществляется при закрытии отчёта и в случае если над данной таблицей были произведены визуальные изменения. Метаданные собой представляют следующую структуру: Dictionary<string, object> treeDisplay [3].

DataGridView

ExDataG ridView

-AllowPaint

-AllowScroll

+CellsStringAlignment

-childSized

-context

+DefBackColor

+ExCells

-grafx

-horizontalSized

-HotSpot

-lastItemPos

-lastNode

-lastPos

-scaleKoef

-tableHeight

-tableWidth

+workTemplate

-ZeroLineMoved

#CheckPomtO

#DrawE m pty R ows ()

+ExDataGridViewO

#MoveHLineO

#MoveVLeftO

#MoveVUneO

#OnCellPaintingO

#OnColumnAddedO

#OnColumnRemovedO

#OnPaintO

#OnResizeO

#OnR owsAd dedO

#OnRowsRemovedO

#OnScroN0

#OnVisibleChangedO

#PointBetweenO

+SetTemplateO

WorkTemplate

-AColl

-ARow

-ChNode

-CrossBitmap

-CurRowEmptySpace

-CurTabColWidth

-defaultPageWidth

-DefFontSize

-EmptyRowsStrings

-grFull

-height_side

-height_up

-width_up

-width_side

-UpBitmap

-TableScale

-TablePen

-symCells

-SideBitmapFull

-masFloat

-mas zeros

#ClearAllResourcesO

+ClearPaintingResourcesO

+DisposeO

^ etCo l u mnsWi dthO

-GetRowEmptySpaceO

-GetTextFontO

-PaintColumnO

-PaintFrameO

-PaintRowO

-PaintTextO

+PaintO

+Paint_cellsO____________

HLine

-height

-node

-x1

-x2

-у________

•HLineO

-node

-width

*

-у1

-У2_____

+VLineO

+column

+row

11

Рис 3. Диаграмма классов компонента ExDataGridView

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

соответствие количества узлов в дереве и тэгов в XML-шаблоне на определённом уровне. Это механизм необходим на случай структурного изменения таблицы (добавление или удаление определённой строки или столбца). В случае неудачной проверки происходит удаление метаданных данной таблицы. Если проверка прошла успешно, то происходит замена значений ширины и высоты заголовочных ячеек в XML-шаблоне на значения находящиеся в дереве-настроек в соответствии с уровнями узлов дерева. Использование данной технологии даёт нам возможность сохранять настройки отображения таблиц даже в случае если в XML-шаблоне изменятся определённые свойства у рабочих ячеек или измениться содержание заголовочной ячейки.

При разработке адаптивных информационных систем так же следует учитывать свойство надёжности. Надёжность системы может быть снижена и нарушена из-за следующих причин:

- ошибки внутри системы (несоответствие версий элементов; ошибки, не выявленные на этапе тестирования);

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

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

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

- в случае недоступности сервера реализовать технологию повторного подключения к нему;

- если клиентское приложение завершается аварийно или сервер недоступен в течение длительного времени необходимо разработать механизм резервного сохранения всех введённых данных, которые не были переданы серверу;

- при первом запуске клиентского приложения после аварийного завершения работы необходимо реализовать средства для восстановления данных из резервной локальной копии;

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

Все выше описанные проблемы решались в АИС «Прокуратура-Статистика» версии 2.0, которая разработана с применением трёхуровневой архитектуры это позволяет обеспечить масштабируемость, безопасность и надёжность разрабатываемого распределённого приложения. Взаимодействие клиентских приложений с сервером осуществляется с использование технологии . NET Remoting.

Контроль совместимости версии в АИС «Прокуратура-Статистика» осуществляется следующим образом: версия сервера получается специальным методом от сервера ServerVersion при запуски клиентского приложения. Далее происходит сравнение версий и в зависимости от результата существуют три пути:

- завершение работы клиента, при полной несовместимости клиента и сервера;

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

- дальнейшая работа клиента при полной совместимости.

Для проверки соединения с сервером в клиентском приложении разработан метод checkConnection(). В нём происходит вызов серверного метода baseServer.ServerTime, в случае возникновения исключения на данном этапе происходит переподключение к серверу методом RestoreConnection, в параметрах у которого указан сеансовый ключ клиента. Данный ключ клиентское приложение получает в процессе запуска в случае успешной аутентификации на сервере. Метод проверки соединения выполняется через определённый промежуток времени в процессе работы клиента и перед основными операции обращения к серверу. Применение данной технологии даёт нам гарантию, что в случае разрыва соединения произойдёт переподключение к серверу и выполнение основых операций взаимодействия с сервером пройдёт успешно.

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

При первоначальном запуске клиентского приложения осуществляется подключение следующего события: System.Threading.ThreadExceptionEventHandler. Это событие возникает в случае возникновения

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

Рис 4. Окно, возникающее в случае критической ситуации.

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

Заключение

Используя предложенные методы можно в достаточно короткие сроки создавать механизмы для адаптации информационных систем, а так же повысить надёжность приложений с клиент-серверной архитектурой. Описываемые программные средства могут рассматриваться как прототипы для аналогичных систем. Подходы реализованы в АИС «Прокуратура-Статистика» версии 2.0.

В дальнейшем планируется разработать систему с более интеллектуальной архитектурой и произвести исследования в области разработки механизмов взаимодействия репозитория метаданных для адаптации с информационной системой.

ЛИТЕРАТУРА

1. Dragan Gasevic Dragan Djuric Vladan Devedzi^ Model Driven Engineering and Ontology Development, Springer-Verlag Berlin Heidelberg 2006, 2009

2. А.А. Мезенков, С.В.Шибанов, Повышение надёжности клиент-серверных приложений в информационных системах, Технологии Microsoft в теории и практике программирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 2010.

3. С.В.Шибанов, А.А. Мезенков, Отображение и адаптация сложных табличных представлений в пользовательском интерфейсе, Технологии Microsoft в теории и практике программирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 2010.

4. С.В.Шибанов, А.А. Мезенков, Активная функциональная панель как средство повышения эффективности пользовательского интерфейса, Технологии Microsoft в теории и практике программирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 2010.

5. Мандел Т. Разработка пользовательского интерфейса. - М.: ДМК-Пресс, 2001.

6. Шибанов С.В., Казакова Е.А., Апаров М.И., Илюшкин А.С. Архитектура метаданных в автоматизи-

рованной информационной системе «Прокуратура-Статистика» как основа сопровождения и разработки// Надежность и качество. Тр. межд. симп.: Под ред. Н.К, Юркова. - Т. 2. - Пенза: Изд-во Пенз. гос.

ун-та, 2008. - с. 298-301.

7. Мезенков А.А., Шибанов С.В., Технологии и средства разработки адаптивных информационных систем, Всероссийская молодежная выставка-конкурс прикладных исследований, изобретений и инноваций.

- Саратов: Изд-во Сарат.ун-та, 2009.-Ч.2.