УДК 51:681.3.06

В.П. Галич, А.О. Васильєв, Р.С. Шевченко, А.Ю. Дорошенко

Застосування об'єктної технології в системах обробки картографічної інформації Internet/Intranet.

Вихід комп'ютерних застосувань в Інтернет і широке застосування мережних технологій висуває нові вимоги до засобів програмування прикладних задач в розподілених мережних середовищах. В статті описані особливості застосування об'єктної технології для обробки картографічної інформації в геоінформаційних системах. Аналізуються можливості застосування трирівневих архітектур та веб технологій в таких системах. Порівнюються два варіанти реалізації картографічних систем та наводяться переваги застосування об'єктних та розподілених технологій.

Вступ

Використання розподілених архітектур для створення сучасних інформаційних систем з багатьма користувачами вимагає вирішення як мінімум двох серйозних проблем, які вимагають матеріальних затрат. Перша проблема - це підвищення вимог до показників продуктивності апаратного забезпечення робочих станцій, а друга - забезпечення підтримки конфігурацій доступу до даних, що зберігаються в системі. Розв'язання цих проблем включає вирішення низки питань, пов'язаних зокрема з експлуатацією всіма користувачами певних спільних ресурсів, з територіальною віддаленістю клієнтів, можливою низькою якістю ліній зв'язку, перевантаженням мережі при збільшенні обсягу даних і т.ін. Традиційно ці питання можна вирішувати двома шляхами: екстенсивним і інтенсивним. Перший з них полягає у збільшенні продуктивності апаратури і пропускної здатності мережі, прокладенні нових ліній зв'язку, перенесенні архівних даних з метою зменшення об'єму бази даних. Зазвичай такий спосіб вимагає значних матеріальних затрат і часто у чистому вигляді є неприйнятним, особливо при великій кількості користувачів і високій швидкості збільшення обсягу бази даних. Інший шлях, інтенсивний, полягає у вдосконаленні організації обслуговування клієнтів та забезпеченні гнучкої архітектури її програмної підтримки насамперед за рахунок створенні нових сервісів, які є спільними для користувачів інформаційної системи. Типовими прикладами для архітектур таких сервісів є CORBA [1-2] та DCOM [16]. Ці сервіси є сервісами проміжного рівня (middleware services), оскільки займають проміжне становище між даними і програмами, які їх обслуговують, з одного боку, та застосуваннями користувачів, що орієнтовані на конкретну предметну область, з другого боку. Такі сервіси звичайно мають мінімальний інтерфейс користувача або навіть взагалі його не мають. Часто вони можуть бути реалізовані для багатьох різноманітних платформ.

Перед авторами цієї роботи стояло завдання розробки системи надання картографічних сервісів для представлення зображень планів міста користувачам в мережі Intranet (головним чином - службовцям Головного управління архітектури та містобудування м. Києва), а також користувачі мережі Internet. Компанією GradSoft була розроблена типова архітектура систем, яка дозволяє отримувати векторні масштабовані плани міст, обирати типи об'єктів, які необхідно відобразити та проводити пошук вулиці або будинку за адресою. Використання трирівневої архітектури системи та об'єктно-орієнтованих WEB технологій дозволяє ефективно побудувати систему, яка б задовольняла цим вимогам.

Географічні інформаційні системи (ГІС).

Побудова електронних карт та географічний аналіз з їх використанням є все більш поширеним застосуванням в інформаційних технологіях [3,18]. Сучасні технології ГІС вже здатні виконувати не лише простий пошук та елементи аналізу при розв'язуванні проблем, що стоять перед організаціями та окремими користувачами, а й використовувати механізми узагальнення та повноцінного аналізу географічної інформації при прийнятті оптимальних рішень, що базуються на сучасних підходах та засобах візуалізації географічних даних. Згідно з визначенням [18] ГІС - це сучасна комп'ютерна технологія для картування та аналізу об'єктів і подій реального світу. Такі технології поєднують традиційні операції роботи з базами даних з перевагами візуалізації та географічного (просторового) аналізу, який є природнім засобом обробки інформації, що може бути нанесена на карту. Ці особливості відрізняють ГІС від інших систем та забезпечують унікальні можливості для їх використання у вирішенні широкого спектру задач, пов'язаних з аналізом та прогнозом, виділенням головних факторів, причин та можливих наслідків, плануванням стратегічних та наслідків поточних рішень. Крім просторових запитів, проведення аналізу та обгрунтування рішень ГІС може виконувати також автоматичну побудову карт, яка є набагато простішою та гнучкішою, ніж в традиційних методах ручного або автоматизованого картографування. Процес починається з побудови картографічних баз даних, які можуть бути неперервними та не пов'язаними з масштабом. Далі, використовуючи таку базу даних, можливо створювати електронні карти або їх тверді копії будь-якої території, масштабу, з необхідним семантичним наповненням. Використання в ГІС сучасних технологій СУБД та Internet/Intranet дає можливість швидкого поновлення, експортування та розповсюдження географічних даних кінцевим користувачам. В даній статті описано підхід до реалізації таких систем на прикладі географічної інформації міста Києва.

Типова ГІС має складатись з п'яти частин і зображена на наступному малюнку.

Апаратні засоби складає комп'ютерна платформа, на якій розгорнута ГІС, а програмне забезпечення містить функції та інструментарій, необхідні для зберігання, аналізу та візуалізації географічної інформації. Дані - найважливіший компонент ГІС. Це інформація про просторове положення об'єктів, а також пов'язана з ними семантична інформація. Виконувачі - це персонал розробників, що працюють з програмними продуктами і розробляють їх застосування для розв'язування конкретних задач. Множину методів утворюють обрані плани та правила роботи кожної ГІС, що складаються у відповідності до специфіки завдань кожної організації.

Далі в роботі використовуються такі поняття картографічних даних як масштаб, географічний об'єкт, шар, растр, вектор та генералізація [4].

Масштабом називають відношення довжини нескінченно малого відрізка на геозображенні до довжини відповідного нескінченно малого відрізка на поверхні еліпсоїда або кулі. Існує велике розмаїття різної інформації, яка повинна бути нанесена на карту. Будь-яку одиницю такої інформації прийнято називати географічним об'єктом. Для побудови карт перш за все класифікується вся множина об'єктів карти. Першим кроком класифікації є виділення шарів картографічної інформації, де кожен шар містить певну множину об'єктів. Для карти міста Києва такими шарами можуть бути берегова лінія Дніпра та водосховищ, парки та зелені зони, система вулиць та кварталів. Далі множину шарів теж можна класифікувати, наприклад, на шари, що є ландшафтними особливостями, шари забудов та ін. Існує відповідність між класифікацією шарів із семантичної точки зору та їх відображеннями на картографічних матеріалах певного масштабу [4]. Вона описана у відповідних державних, галузевих стандартах та керівних документах.

Графічне відображення цієї інформації звичайно може бути оформлене у двох форматах: растровому або векторному. Растрове зображення визначає матрицю елементарних пікселів, які формують зображення. Проте семантичний аналіз растрового зображення, наприклад для виділення об'єктів, визначення масштабу або пошуку зразка, є досить складною задачею, що може вирішуватись за допомогою систем штучного інтелекту і тому не є придатним для використання у критичних до часу елементах інтерактивної системи. З іншого боку, кінцевими елементом інтерфейсу користувача є саме растрове зображення, яке формується за допомогою пікселів дисплею. Векторне зображення це математичний опис зображення як набору геометричних примітивів. Використання векторного формату дозволяє досить ефективно реалізувати семантичні операції над картографічними об'єктами.

Генералізацією називають узагальнення зображень малих масштабів відносно більших, яка здійснюється у зв'язку з тематичним призначенням або технічними умовами отримання самого зображення [4].

Функціональні та технологічні вимоги до системи

Функціональні вимоги до картографічного застосування можна розподілити на вимоги до серверу застосувань, серверу баз даних та клієнтської частини. До функцій серверу застосувань можна віднести: навігацію користувача по масштабованому плану міста, вибір району для подальшого його детального відображення, зміна масштабів детального відображення вибраного району, обробка запитів на пошук адреси та відображення знайденої інформації. Функціями серверу баз даних є: зберігання всіх необхідних даних та виконання запитів, які надходять від серверу застосувань. До клієнтської частини ставляться вимоги відображення інформації, отриманої від сервера застосувань, та формування і передача запитів до нього.

Звичайно картографічне застосування повинне задовольняти таким технологічним вимогам, як масштабованість, відкритість, переносимість, ізольована розробка, та "легкість" клієнтів, що означає зосередження всієї обробної частини застосування на серверній стороні. Масштабованіcть - це можливість підвищення обчислювальної потужності комп'ютерної системи (наприклад, збільшення кількості операцій або тракзакцій за одиницю часу) за рахунок збільшення кількості обчислювальних модулів або заміни їх на більш потужні. Відкритість гарантує, що система безпроблемно інтегрується в існуючі або нові застосування. Крім того обчислювальна система повинна функціонувати в гетерогенних і, що найбільш важливо, розподілених середовищах. Відкритість безпосередньо пов'язана із поняттям масштабованості. Вона його розширює, оскільки вимагає одночасної підтримки багатьох платформ, мережних середовищ та серверів баз даних. Крім того, застосування повинно забезпечувати легке підключення зовнішніх застосувань. Практично це означає, що воно повинне мати відкрите інтерфейс користувача АРІ та підтримку технологій COM (DCOM) або CORBA, а також підтримка існуючих стандартів у даній галузі [5-6]. Вимога переносимості забезпечує виконання застосування коду на інших платформах без істотної втрати функціональності. Фактично вона є окремою частиною вимоги відкритості.

Ізольована розробка означає властивість розподілених застосувань через свою модульну основу дозволяти ізольовані один від одного створення і заміну модулів (компонент). Вся система розбивається на автономні модулі, робота над якими може вестись окремо від інших [16]. В той же час модулі можуть взаємодіяти між собою. Для цього вони повинні підтримувати протоколи і інтерфейси, що визначають спільні принципи їх взаємодії. Оскільки методи, що існують в модулях, ізольовані від методів інших модулів, вони можуть розроблятися незалежно. Таким чином, міра реалізації компонент не залежить від стану коду в інших частинах системи. Стає можливою паралельна робота декількох команд над різними частинами застосування або системи. Взаємодія ж між різними модулями відбувається через встановлені протоколи і інтерфейси.

Легкі клієнти у розподіленій системі надають можливість перенести всю функціональну логіку інформаційної системи на її серверну частину. У цьому випадку клієнти, з якими спілкується користувач, можуть бути виконані невеликими і легкими. Системні ресурси користувача виявляються більш вільними, а весь тягар функціональної логіки реалізується високопродуктивним сервером (або мережею серверів). При цьому клієнт може мати доступ до практично необмеженої кількості сховищ інформації та інших об'єктів. З'являється можливість створення "легких" компонент, придатних для швидкого завантаження через мережу Internet і запуску на комп'ютері клієнта, До такого роду застосувань можна віднести аплети Java та ActiveX компоненти.

Архітектура картографічних застосувань

У більшості випадків можна сказати, що структура вхідної задачі загалом визначає архітектуру системи. Картографічні застосування, по-перше, повинні мати підсистему зберігання векторних даних, інтегрованою з системою вибірки. По-друге: має існувати система обробки вибраних даних, яка взаємодіє з іншими підсистемами в термінології картографічних понять: масштаб, шар, географічний об'єкт. По-третє: має бути система відображення картографічної інформації та взаємодії з користувачем. Підсистема відображення повинна реалізувати відображення векторних даних у растровій формі, яка відповідає відображенню цих даних на графічних дисплеях. Підсистема зворотного зв'язку має організовувати кінцевий інтерфейс користувача. І останнє, якщо мова йде про систему з інтерфейсом всесвітньої мережі WWW (далі скорочено, веб) , то повинна існувати також підсистема доставки та кешування елементів кінцевого інтерфейсу. Таким чином, типова архітектура подібних систем має відповідати наступній схемі.

Мал.1. Архітектура застосування

Реалізації систем картографічних застосувань

В даній роботі були побудовані дві системи, що реалізують вищенаведену архітектуру картографічних застосувань. Перша була втілена на основі Java з використанням наступних засобів: веб-браузер Internet Explorer 5, JDBC, веб-сервер Apachе [19], modCBroker [8], бібліотека обробки графіки Acme (www.acme.com). Картографічна інформація містилася в базі даних Oracle у вигляді векторних об'єктів: ліній, полігонів, прямокутників, кривих. Їх даних здійснювалася засобами Java та JDBC. Оскільки відображати картографічні дані потрібно було у графічному форматі, тому необхідно було здійснювати перетворення вибраних векторних об'єктів у растрові малюнки. Це було здійснено мовою Java із застосуванням спеціалізованої бібліотеки Acme. Остання дозволяє ефективно продукувати такі широковживані растрові формати як jpeg, gif та ppm. Функціональне начиння було реалізовано в сервлетах із використанням модуля Apache ModCBroker, розробленого компанією GradSoft. Даний модуль здійснює прозору трансляцію HTTP запитів до сервера CORBA. Згенеровані сервлетами зображення посилаються в гіпертекстовий потік для браузера клієнта. Користувач має справу із малюнком карти Києва та навігаційними кнопками, які дозволяють переміщатися по карті та збільшувати або зменшувати масштаб. На малюнку 2 зображено технологічні елементи даної реалізації.

Мал.2. Технологічні елементи реалізації на основі Java.

Поєднання технологій Java та CORBA має свої переваги та недоліки. До переваг можна віднести здатність Java спрощувати розповсюдження коду у великих системах CORBA, оскільки такий код може застосовуватися і керуватися централізовано із сервера [17]. При необхідності потрібно лиш поновити код на сервері і потім надати клієнтам можливість його отримувати. Також до позитивів можна зарахувати той факт, що Java є зручним засобом написання об'єктів CORBA [17]. Вмонтовані можливості Java для мультипоточності, збирання сміття та обробки помилок полегшують написання мережних об'єктів. Об'єктна модель Java доповнює модель CORBA і вони обидві використовують концепцію інтерфейсів для відмежування визначення об'єкта від його реалізації. До недоліків можна зарахувати низьку продуктивність Java на таких складних математичних обчисленнях, як обробка зображень та криптографія.

Інший варіант реалізації було одержано в системі GradMap, що була реалізована компанією GradSoft. Вона має три рівні: рівень бази даних, рівень застосувань та рівень клієнта. На рівні бази даних працює сервер баз даних Oracle, який зберігає геометричні образи об'єктів, а також пов'язану семантичну інформацію: назва, описи та ін. Як сервери застосувань використовуються об'єкти CORBA. Завданням кожного окремого серверу є аналіз запиту користувача, формування відповідної об'єктної моделі карти, растеризація, генералізація, кешування, формування геометричного відображення карти та подання відповідних результатів клієнту. Клієнтом системи є веб-браузер, який забезпечує користувачеві всі доступні функції системи, формує запит і представляє результат роботи системи.

Функції взаємодії сервера застосувань та браузера для клієнта реалізуються засобами ModCBroker [8], а взаємодія сервера застосувань та СУБД виконується на основі технології UAKGQuery - обидва продукти розроблені компанією GradSoft [8-9]. Основна їх перевага полягає у тому, що вони дозволяють виконувати запити зчитування, запису даних об'єктами CORBA до будь-якої системи управління БД.

Технологічні елементи реалізації даної системи зображено на малюнку 3.

Мал.3. Технологічні елементи системи GradMap.

Побудована об'єктна модель даних завжди потребує деякого графічного представлення. Для запису графічної інформації в системі була використана бібліотека FlashSDK (www.macromedia.com). Вона дозволяє сформувати графічні об'єкти та записати їх в файл формати .swf, що дає змогу використовувати переваги Flash технології. На мал. 4 наведено приклад зображення засобами універсальної мови моделювання UML спрощеної схему класів сервера застосувань. На рівень прикладних об'єктів тут винесені такі поняття як шар (Layer), що є сукупністю об'єктів зображення (ImageObject), таких як полігон або незамкнутий контур. Представлення даних, як і параметри конкретного запиту користувача, ізольовано від шару цих об'єктів за допомогою спеціального класу-обробника (DataHandler). Інші аспекти, такі як блок генералізації або блок кешу запитів на цій схемі не представлені:

Мал.4. Спрощена діаграма UML для класів сервера бізнес-логіки.

Розробка GradMap показала, що при сучасному розвитку технології моделювання UML модель системи може грати лише допоміжну ілюстративну роль у великих проектах. Побудована повна UML модель системи містить в собі більше 300 об'єктів і тому використовувати програмні засоби роботи з моделлю виявилось практично неможливо внаслідок їх низької продуктивності.

Нижче на мал. 5. подано елемент інтерфейсу кінцевого користувача картографічного застосування у системі GradMap.

Мал. 5. Приклад інтерфейсу користувача.

Висновки

Досвід розробки розподіленої системи картографічних застосувань виявив певні особливості таких розподілених комплексів. Перша особливість - це використання типової архітектури з можливістю вибору елементів реалізації. Наприклад, при необхідності можна використовувати CORBA API підсистеми географічних об'єктів (приклад GradMap) у комбінації з серверним генеруванням растрового зображення засобами Java (перший варіант реалізації). Друга характерна риса - це використання багаторівневої архітектури, де кожен рівень відповідає певному рівню абстракції, тобто бази даних, геооб'єктів, інтерфейсу користувача, взаємодії з веб. І третя особливість - це використання компонентної моделі. В середовищі CORBA об'єкт стає інтелектуальною програмною одиницею, незалежним компонентом, завершеною частиною програмного коду із такими особливостями, як:

Компонент виступає одиницею роботи і розподіленості в розподілених об'єктних системах. Інфраструктура розподілених об'єктів CORBA забезпечує прості механізми для того, щоб компоненти стали автономними, самокерованими і взаємодіючими. Технологія розподілених об'єктів CORBA дозволяє збирати в єдине ціле складні інформаційні клієнт-серверні системи, просто зв'язуючи і розширюючи їх компоненти, при чому можна модифікувати об'єкти, не впливаючи на інші компоненти або на спосіб їх взаємодії. Це потужний засіб, який успішно вирішує проблему, для якої він створювався, а саме проблему взаємодії. Уже сьогодні намічаються тенденції зсуву архітектури складних обчислювальних систем від однорівневої до двох- та багаторівневої архітектури [10]. Розподілені об'єкти та Web дозволяють розбити важкі монолітні застосування на більш керовані легкі компоненти, які мають властивість існувати в гетерогенних середовищах.

У майбутньому досвід використання багаторівневих архітектур буде поширюватись на більш спеціалізовані системи, такі як геоінформаційні. Саме застосування таких архітектур та веб-технологій дозволяє розширити можливості систем обробки картографічної інформації. Застосування об'єктних технологій дозволяє зменшити загальну вартість складних систем за рахунок повторного використання коду і можливості ретельної доробки компонент на різних стадіях життєвого циклу програми.

  1. Object Management Group. formal/98-12-01 The Common Object request Broker: Architecture & Specifications. CORBA/IIOP 2.3.1 , 712p. (ftp://ftp.omg.org/pub/formal/98-12-01.pdf)
  2. Object Management Group. Oma: A Discussion of the Object Management Architecture January 1997, 44p (www.omg.org/library/oma/oma-all.pdf)
  3. Open Gis Consortium. Open GIS Abstract Specification - 99-AS-RFP009 24 June 1999 http://www.opengis.org/
  4. Геоинформатика.Толковый словарь основных терминов. Баранов Ю.Б., Берлянт А.М., Капралов Е.Г., Кошкарев А.В., Серапинас Б.Б., Филиппов Ю.А. Под редакцией А.М.Берлянта и А.В.Кошкарева. Москва, ГИС-Ассоциация, 204 с. http://193.233.5.209/info1/gis_serv/our_publ/Dictionary/index_slov.htm
  5. ГОСТ Р 50828-95 Геоинформационное картографирование. Пространственные данные, цифровые и электронные карты. Общие требования.
  6. ГОСТ Р-51353-99 Геоинформационное картографирование. Метаданные электронных карт. Состав и содержание
  7. M. Fowler. " Analysis Patterns and Business Objects". OOPSLA'96, 1996.
  8. R. Shevchenko, S. Krisanov. Mod_cbroker: Programming Guide. 2001.
  9. R. Shevchenko. UAKGQuery: Programming Guide., 2001.
  10. R. Shevchenko, A. Doroshenko. A Method of Mediators for Building Web Interfaces of CORBA Distributed Enterprise Applications. Lecture Notes in Informatics V. 4 - Proceeding of Information Systems Technology and its Applications 2001. Gesselschaft fur Informatik, 2001, ISBN 3-88579-331-8.
  11. R. Shevchenko, A. Doroshenko. Techniques for Increasing Performance of CORBA Based Distributed Applications. Parallel Computer Technologies, Proc. 6-th int, conf. PACT2001 LNCS vol 2127 pp 319-328.,Springer-Verlang, 2001
  12. Дж. Вебер. Технология Java. BHV - Санкт-Петербург, 1997.
  13. B. Stroustrup. The C++ Programming Language (3rd edition). Addison Wesley Longman, Reading, MA. 1997. ISBN 0-201-88954-4. 920 pages. Softcover.
  14. Bjarne Stroustrup. The Design and Evolution of C++. Addison Wesley, Reading, MA. 1994. ISBN 0-201-54330-3. 472 pages. Softcover. (Often called D&E).
  15. Открытые системы: концепция или реальность. Открытые системы, #04/1993
  16. С. Семихатов. Технологии WWW, Corba и Java в построении распределенных объектных систем. http://www.javable.com/docs/jav_dist/
  17. Р. Орфали, Д. Харки. Java и CORBA в приложениях клиент-сервер. Лори, 2000, ISBN 5-85582-092-0.
  18. Географические информационные системы. ООО Дата+. Москва. http://www.dataplus.ru/
  19. Ben Laurie and Peter Laurie, "Apache. The Definitive Guide", O'Reilly, 1997, ISBN 1-56592-250-6.

V.P.Galych, A.O. Vasyliev, R.S. Shevchenko, A.Yu. Doroshenko

Application of object technology in Internet/Intranet cartographic information processing systems

Widespread of Internet computer applications and network technologies puts forward the new requirements to ways of programming applied tasks in the distributed network environments. Features of object technology deployment for processing the cartographic information in geoinformation systems are described. Opportunities for application of three-level architecture and Web technologies in such systems are analyzed. Two variants of realization of cartographic systems are compared and the advantages of application object and distributed technologies are resulted..

Інформація про авторів.

Галич Віталій Петрович - студент магістеріуму НаУКМА. Область наукових інтересів - дослідження засобів побудови та інженерії розподілених програмних систем та їх застосування.

Васильєв Андрій Олександрович - магістрант факультету інформатики та обчислювальної техніки Національного технічного університету України ("КПІ"), програміст компанії GradSoft. Галузь наукових інтересів - математичні і формальні моделі в прикладному програмуванні, технології реалізації розподілених систем.

Шевченко Руслан Сергійович - аспірант Інституту програмних систем та головний ахітектор програмних систем компанії GradSoft. Наукові інтереси зосереджені в ділянці досліджень моделей і методів програмної інженерії розподілених систем.

Дорошенко Анатолій Юхимович доктор фіз.-мат. наук, заступник директора з наукової роботи Інституту програмних систем НАН України та завідувач кафедрою мережних технологій факультету інформатики НаУКМА. Область наукових інтересів - моделі та методи паралельної обробки інформації, архітектури паралельних і розподілених обчислювальних систем.