Наблюдаемость сделанных изменений является одним из важных факторов в программной реализации рассматриваемого механизма репликации. Необходимо обнаружить сам факт изменения графического образа, семантики или прагматики картографического объекта и определить степень его влияния на информативность.
Существуют объективные ограничения наблюдаемости изменений. Например, изменение атрибутивных данных объекта (записи из внешней реляционной БД) обнаруживается только сравнением исходного и конечного значений ее полей. Это требует переработки соответствующих программных модулей и неприемлемо в ряде систем. Другим примером является изменение контура земельного участка: его площадь может остаться прежней, однако расположение может существенно влиять на решаемую задачу. Наблюдаемость такого факта ограничена наличием соответствующей аналитической процедуры. Имея подобные ресурсные ограничения, представляется целесообразным учитывать наблюдаемость нечеткой переменной, зависящей от загружаемых программ модификации информационной базы. Например, наблюдаемость может считаться высокой при изменении графического образа объекта, невысокой - при изменении его атрибутов, низкой - при изменении гиперссылки.
Примером механизма для обеспечения наблюдаемости является реализация объектов-реакторов в системе AutoCad 2000 [5]. С точки зрения прикладного программирования данная система является объектно-ориентированной средой для выполнения интерпретируемых программ на AutoLisp и сервером автоматизации ActiveX. Мощные средства векторной графики и трехмерного моделирования с помощью дополнительного пакета-надстройки превращают AutoCad в геоинформационную систему AutoCad Map.
Реализация СКР может строиться на объектах-реакторах, каждый из которых принадлежит к одной из категорий:
- реакторы редактирования связываются с выполнением команд редактирования изображения;
- реакторы связи оповещают о загрузке внешних программ в адресное пространство среды AutoCad 2000;
- реакторы БД сигнализируют о добавлении, удалении и модификации объектов БД чертежа;
- реакторы документов оповещают об открытии и закрытии, активизации и дезактивизации чертежей как документов в многодокументном интерфейсе Windows;
- реакторы объектов сообщают о создании, модификации и уничтожении произвольных объектов.
Реактор является не только средством быстрого реагирования на модификацию, но и средством ее локализации. СКР устанавливает реакторы на графические примитивы, команды редактирования и внешние программы, делающие наблюдаемым факт изменений. Содержание изменений при необходимости может быть оценено последующим сравнением начального состояния объекта с состоянием после модификации.
Эффект выигрыша по объему трафика можно оценить следующим образом. Пусть V - средний объем в байтах рабочей области карты; Тсоед — среднее время существования соединения; Хизм — интенсивность модификации рабочей области, тогда средний объем трафика составит (в байтах) V = Тсоед • Хизм ■ РКИ .
Если обозначить через Хсущ интенсивность существенных изменений, то абсолютный выигрыш составит AV = Тсоед ■ (Хизм - Хсущ) ■ РКИ .
Чем сложнее общая карта ГИСС, тем заметнее тенденции Хизм ^ Хсущ ^ 0 .
Рассмотренный в работе принцип репликации в ГИСС использует оценку существенности изменений, выполненных над источниками картографической информации. Реализация принципа предполагает создание серверной компоненты репликации. Экспертная система серверной компоненты на основании нечетких рассуждений принимает решение о необходимости репликации. Локализация изменений осуществляется посредством программных объектов-реакторов.
Список литературы
1. Калиниченко Б.О. Аснхронное тиражирование данных в гетерогенных средах //СУБД .- 1996.- № 3.
2. Беляков С.Л. Картографические образы в информационно-управляющих системах // Приборы и системы. Управление, контроль, диагностика.- 2000.- № 5.
3. Берлянт А.М. Образ пространства: карта и информация.-М.: Мысль, 1986. —240 с., ил.
4. Берштейн Л.С., Боженюк А.В. Нечеткие модели принятия решений: дедукция, индукция, аналогия.-Таганрог: Изд-во ТРТУ, 2001.
5. AutoCAD2000i. Visual Lisp Developer's Guid.- Autodesk, Inc.-2000.
ПОДХОД К РАЗРАБОТКЕ ГРАФИЧЕСКИХ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ СЕРВЕРНЫХ СИСТЕМ IBM AS400
Ю.М. Вишняков, С.Ю. Новиков, С.В. Таранов
Прикладная система IBM AS/400 представляет собой семейство миникомпьютеров с единой архитектурой аппаратных и программных средств с соб-
ственным терминальным оборудованием. Л8/400 имеет прочную репутацию надежного, производительного сервера для транзакционных систем. Эта
система была признана лучшей бизнес-платформой среди систем среднего класса и завоевала престижные премии, в том числе премию Белдриджа за соответствие высшим стандартам качества. Все функции и возможности, используемые в бизнесе, полностью интегрированы в операционную систему IBM Operating System/400 (OS/400) и позволяют создавать надежные информационные структуры любой степени сложности. Поэтому AS/400 распространяется на рынке только в виде полностью законченной системы.
С появлением и широким распространением персональных компьютеров (ПК) и интернет-коммуникаций остро обозначилась потребность в удаленном взаимодействии ПК с серверами AS/400. В этом направлении ведущими производителями программного обеспечения (ПО) предприняты определенные шаги и представлено на рынок довольно много различных решений, эмулирующих работу терминала AS/400 на ПК по протоколу TN5250 [1-3]. Возможности таких эмуляторов по удобству работы и по функциональности намного превосходят возможности, предоставляемые пользователю стандартным терминалом от IBM.
На рынке ПО эмуляторы TN5250 бывают текстовые и текстографические с использованием элементов Graphical User Interface (GUI). Эмуляторы, использующие текстовый экран для вывода информации, появились уже достаточно давно, они нетребовательны к ресурсам и некоторые из них могут работать без графической среды. Например, Mocha W32 TN5250 компании MochaSoft, Nexus Mainframe Terminal компании Nexus Integration. Типичные тек-стографические эмуляторы - это Host On-Demand (IBM), MorphMaster (Better On-line Solutions), New Look (Look Software), Jwalk (SeaGull). Преимущества графического эмулятора над текстовым очевидны. Основной задачей графического эмулятора терминала является максимально удобное представление информации, получаемой от AS400, с точки зрения GUI. Однако данные решения не в полной мере устраивают пользователей, поскольку они частично, а чаще не всегда корректно реализуют возможности графической среды ПК. Это является следствием того, что протокол взаимодействия клиента с сервером AS400 - TN5250 не позволяет оперировать стандартными элементами управления Windows. Поэтому GUI-фикация экранов AS/400 требует значительных усилий для корректного отображения среди элементов управления. Так, основными недостатками текстового отображения являются:
- фиксированный размер экрана (протокол TN5250 позволяет формировать два типа экранов 80x24 и 132x27);
- в мультистраничном экране переход на следующую страницу осуществляется с помощью клавиш <PgUp> и <PgDown>;
- текстовое отображение окон (в качестве разделителя предыдущего экрана и нового окна используются специальные символы);
- крайне неудобная работа с таблицами с точки зрения GUI. Представление таблиц ограничивается
шириной тексториентированного экрана терминала. Поэтому таблицы, содержащие достаточно много полей на экране, отображаются в несколько строк.
Таким образом, обычному пользователю GUI-систем очень трудно работать с тексториентирован-ными системами.
Графический эмулятор должен служить своего рода мостом между старым представлением данных (текстовым) и новым (графическим). Причем главное требование к нему заключается в том, чтобы не требовалось никаких переделок прикладных пользовательских систем, работающих на серверной стороне (AS400).
В настоящий момент в подавляющем большинстве текстографических эмуляторов терминала IBM 5250 используется так называемый механизм статического распознавания. Его суть заключается в том, что для каждого экрана оператором создается графическая экранная форма, описывающая тип данного экрана. Такой подход эффективно работает на программных системах с небольшим количеством точно определенных экранов и жестко привязан к конкретной пользовательской прикладной системе. Увеличение числа экранов приводит к замедлению скорости работы, увеличению размеров, и общая эффективность работы эмулятора падает за счет большого объема хранимой информации.
Предлагаемый метод, основанный на динамическом распознавании экранов, является универсальным. Классификация проводится по динамическому набору признаков экранов, по так называемым правилам. Информация, приходящая с сервера, подвергается анализу, фильтруется через механизм статических шаблонов, и в случае необходимости некоторые функции (такие как "докачка" данных последующих страниц с сервера и др.) выполняются программой автоматически. Исследования объема обменных процессов показали, что информацию более целесообразно порционировать на страницы, число которых зависит от скорости установленного соединения клиент-сервер и определяется пользователем по его усмотрению. Таким образом, общение клиента с сервером проходит в два этапа.
1. Этап распознавания. На этой стадии полученная с сервера 5250 последовательность преобразуется во внутренний формат и передается на модуль фильтрации. Здесь, используя данные ре-позитория, пришедшие данные классифицируются на объекты, классы и группы объектов, отсеиваются ненужные данные и формируется выходное отображение.
2. Этап динамического управления входящим потоком введен для расширения функциональности и повышения удобства работы с эмулятором. На этой стадии автоматизируются многие функции управления программой, такие как автоматическая "докачка" данных, получение с сервера контекстной информации и пр. Благодаря этому пользователь работает с многостраничными данными большого объема, как это он делал бы, например, в Microsoft Office, используя функции скроллинга.
Таким образом, разработанный эмулятор терминала позволяет:
- устанавливать соединение с серверами Л8400 по протоколу ТМ5250;
- работать в двух режимах 24x80 и 27x132;
- распознавать загрузочный экран по заранее заданному шаблону;
- распознавать меню Л8400 и отображать его в отдельной панели;
- докачивать меню;
- распознавать функциональные ключи;
- докачивать функциональные ключи (в некоторых экранах Л8400 описание функциональных ключей не может быть получено с помощью одного только распознавания экрана, необходима отсылка специального функционального ключа, последующего распознавания полученной информации и возврат сервера в исходное состояние);
- распознавать окна Л8400;
- докачивать содержимое окон;
- обеспечивать корректную работу пользователя в докаченном мультистраничном экране;
- распознавать элементы экрана: метки, поля ввода пароля, ссылок, сообщения об ошибке, memo-поля;
- распознавать таблицы различной степени сложности;
- докачивать содержимое таблиц;
- копировать содержимое таблиц в буфер;
- копировать часть экрана в буфер.
С целью построения межплатформенного решения в качестве средства разработки была использована Java. Все решения по GUI практически апробированы на базе серверной системы AS/400 и подтверждают правильность подхода.
Разработка GUI для серверов семейства AS/400 выполнена в международной лаборатории ELDIC в рамках исследования по созданию систем безбумажной обработки информации.
Список литературы
1. IBM 5250 Information Display System. Functions Reference Manual (SA21-9247-6).
2. IBM 5494 Information Display System. Functions Reference Manual (SC30-3533-04).
3. RFC: 1205, 2877.
ОРГАНИЗАЦИЯ ЭЛЕКТРОННЫХ ХРАНИЛИЩ ДОКУМЕНТОВ
Ю.М. Вишняков, А.Н. Толкачев
С развитием компьютерных технологий способ хранения информации в печатном или рукописном виде перестал отвечать требованиям сохранности и оперативности доступа в науке, бизнесе и искусстве. Очевиден переход к электронным формам хранения документов. На этом пути должны быть решены две кардинальные проблемы: проблема электронного документа и средств манипулирования им и проблема перевода информации из традиционной формы в электронную.
В ближайшем будущем печатная информация будет являться основным источником формирования электронных библиотек (ЭБ) и архивов, поэтому созданию средств и методов перевода информации больших объемов в электронную форму придается первостепенное значение. Эта проблема решается на основе так называемых скантехнологий, которые интенсивно развиваются.
ЭБ можно определить как информационную систему, позволяющую надежно сохранять и эффективно использовать разнообразные коллекции электронных документов (ЭД) (текстовых, изобразительных, звуковых, видео и др.), локализованных в самой системе, а также доступных ей через телекоммуникационные сети. Интенсивное развитие и внедрение /иГегиеГ//иГгдиеГ-технологий дают возможность использования единого информационного пространства как универсальной платформы интеграции и обмена информацией.
При этом объединение ресурсов не обязательно осуществляется физически - оно может быть вирту-42
альным и должно обеспечивать целостность информационного пространства для пользователя. Так, ЭБ должны обеспечивать работу с гетерогенными БД или системами БД, обеспечивая пользователя эффективным информационным поиском независимо от особенностей конкретных информационных систем, к которым осуществляется доступ.
В ЭБ должны быть предусмотрены возможности ввода или удаления объектов, интеграции, реструктуризации и прочие операции. Необходимо подчеркнуть, что эти возможности должны распространяться в основном (а возможно, и только) на информационные объекты, например, на ЭД, а не на содержащуюся в них информацию.
ЭБ должна сохранить привычные формы представления информации пользователю, в противном случае это приведет к явному отходу от сложившихся традиций и к потере спроса на такую информацию. Отсюда решение проблемы ЭД требует разрешения следующего противоречия. ЭД должен максимально точно воспроизводить исходное печатное издание, что легко выполнимо, если это издание представлять в виде графического образа, факсимильно. С другой стороны, графическое представление является самым плохим с точки зрения поисковых процедур и потребных информационных ресурсов. В этом смысле более удобным является представление информации в алфавитно-цифровой форме, допускающей посимвольную обработку. Это легко достижимо путем представления исходной информации в виде простых текстовых файлов. Однако