Содержание к диссертации
Введение
1. Геоинформационные системы, проблемы разработки и использования 11
1.1. Анализ возможностей современных ГИС 12
1.1.1. Обзор существующих программных средств создания ГИС-приложений 13
1.1.2. Объектные технологии в ГИС 17
1.1.3. Модели представления знаний предметной области ГИС 19
1.1.4. Модели пространственных данных ГИС 23
1.1.5. Поддержка принятия решений в ГИС 25
1.2. Проблемы разработки ГИС 27
1.2.1. Концептуальные проблемы 28
1.2.2. Технологические проблемы: хранение данных 30
1.2.3. Проблемы работы ГИС в сети 31
1.3. Проблемы топологических отношений в ГИС 32
1.3.1. Внутриобъектные топологические отношения 32
1.3.2. Линейно-узловая топология 33
1.3.3. Концептуальные отношения 34
1.3.4. Проблема обмена цифровыми картами между различными ГИС 36
1.3.5. Возможности интеграции объектного и топологического подходов 37
1.4. Проблемы взаимодействия компонентов в распределенной ГИС 39
1.4.1. CORBA 42
1.4.2. Microsoft DCOM/COM+ 44
1.4.3. Web-сервисы 45
1.4.4. Сравнительный анализ технологий взаимодействия компонентов системы 48
1.5. Постановка задачи исследования 51
Выводы по Главе 1 56
2. Методика разработки интеллектуальных ГИС на основе настраиваемой объектной модели предметной области 58
2.1. Выбор средства разработки ядра ГИС 62
2.2. Выбор технологии долговременного хранения объектов 65
2.2.1. Поддержка сложных объектов 67
2.2.2. Поддержка отношений между объектами 67
2.2.3. Поддержка транзакций и блокировок 68
2.2.4. Сравнительный анализ рассмотренных подходов 70
2.3. Разработка коммуникационной подсистемы 72
2.4. Разработка настраиваемой объектной модели предметной области ГИС 74
2.5. Оценка эффективности методики разработки интеллектуальных ГИС 81
Выводы по Главе 2 89
3. Настраиваемая объектная модель предметной области интеллектуальной ГИС на основе концепции метаданных 90
3.1. Модульная архитектура интеллектуальной ГИС 93
3.2. ГИС-объекты 96
3.3. Метаданные и метаклассы 99
3.4. Поля и методы ГИС-объектов 105
3.4.1. Примитивные типы полей ГИС-объектов 105
3.4.2. Объектные типы 106
3.4.3. Свойства полей объекта 107
3.4.4. Методы объектов 108
3.4.5. Регистрация методов и общих функций 110
3.5. События в объектной модели 111
3.6. Задачи в объектной модели как интерфейсы ГИС-объектов 113
3.7. Встроенный язык управления ГИС-объектами 116
3.7.1. Методика реализации интерпретатора встроенного языка 117
3.7.2. Язык управления ГИС-объектами SOML 123
3.8. Оценка эффективности использования настраиваемой объектной модели 129
3.8.1. Создание объектов 130
3.8.2. Чтение/запись полей объектов 130
3.8.3. Загрузка объектов из подсистемы долговременного хранения 132
3.8.4. Передача списка объектов по локальной сети 133
Выводы по Главе 3 135
4. Средство разработки объектных моделей предметной области ГИС 136
4.1. Пользовательский интерфейс 137
4.1.1. Настройка полей и свойств метакласса 139
4.1.2. Визуальный дизайн экранных форм 142
4.2. Подсистема хранения объектов 146
4.2.1. Структурированное хранилище на базе СОМ-технологии 147
4.2.2. Транзакции и уровни блокировки 149
4.2.3. Оптимизация доступа 150
Выводы по Главе 4 154
Заключение 155
Список литературы 158
- Обзор существующих программных средств создания ГИС-приложений
- Проблемы взаимодействия компонентов в распределенной ГИС
- Разработка настраиваемой объектной модели предметной области ГИС
- Методика реализации интерпретатора встроенного языка
Введение к работе
Эффективность использования геоинформационных технологий в различных сферах трудовой деятельности человека определяется прежде всего тем фактом, что 85% информации, с которой сталкивается человек в своей жизни, имеет территориальную привязку. Геоинформационные системы (ГИС) активно внедряются в различных областях управления, промышленности, транспорта, экологии, здравоохранения и т.д.
В настоящее время ГИС все чаще начинают применяться для решения задач моделирования процессов и ситуаций, что позволяет говорить о новом классе интеллектуальных геоинформационных систем. Однако, при разработке и использовании таких систем, особенно предназначенных для работы в распределенной среде, неизбежно возникает ряд проблем, унаследованных от традиционных топологически-ориентированных и объектно-ориентированных подходов к построению ГИС.
«Топологические» ГИС слабо поддерживают, либо вовсе не поддерживают, объектно-ориентированные модели предметной области, а в «объектных» ГИС топологические отношения между объектами обычно представлены в очень неполном виде.
Поскольку в ГИС графические объекты связаны с табличными данными, необходимо эффективно обрабатывать графику и семантику одновременно, что усложняется гигантскими объёмами информации. Интеллектуальные ГИС к тому же должны обеспечивать комплексный анализ и интерпретацию разнотипных данных, поддержку принятия решений и моделирование в распределенной среде. Отсюда следует, что для таких ГИС необходимо разрабатывать специализированные объектные модели предметной области с возможностью установления любых необходимых топологических связей между объектами и классами объектов.
В связи с этим, тематика исследований, затрагивающая вопросы создания интегрированных объектно-топологических моделей ГИС, является крайне актуальной.
Другой круг проблем разработки интеллектуальных ГИС связан с повышенной сложностью самих решаемых задач. Абсолютное большинство проектов по созданию таких систем — крупные, а число ошибок в таких проектах увеличивается экспоненциально в зависимости от их объема.
В настоящее время принято различать ряд направлений повышения качества программного обеспечения. К наиболее известным относят:
стандартизацию процессов проектирования и разработки программного обеспечения [55,56,58];
создание и использование моделей оценки уровней зрелости организаций- разработчиков программного обеспечения [59, 60];
разработку и сопровождение механизмов повторно используемого кода [57,63,64];
совершенствование моделей жизненного цикла программного обеспечения [57,61,62].
В рамках последнего направления исследуются методы разработки легко сопровождаемых и быстро адаптируемых к изменениям требований программных систем.
Новая на сегодня компонентно-ориентированная парадигма в области разработки программных систем позволяет разработчикам, не отягощенным грузом старых решений, создавать развитые и конкурентоспособные изделия, используя современный инструментарий. Сегодня разработка геоинформационного интерфейса полнофункциональной ГИС занимает не более 4-6 месяцев для коллектива из 5 человек, поскольку современный инструментарий разработчика самостоятельно решает проблемы, которые
раньше приходилось решать самим разработчикам или ждать решения от соответствующих фирм.
Однако данная парадигма требует соответствующего совершенствования методик разработки программного обеспечения, в том числе и с помощью разработки быстро адаптируемых моделей предметной области.
Следовательно, решение проблемы повышения качества программного обеспечения ГИС также обуславливает актуальность решаемой в диссертации научной задачи.
Цель работы. Целью диссертационной работы является разработка методики создания интеллектуальных геоинформационных систем на основе настраиваемой объектной модели предметной области ГИС в целях снижения затрат на моделирование, создание и сопровождение ГИС.
Задачи исследования. В диссертационной работе для решения главной научной задачи также решается ряд частных задач, а именно:
выявление требований, которые предъявляются к интеллектуальным ГИС как к специализированным системам, предназначенным для работы в распределенной среде;
реализация настраиваемой объектной модели предметной области ГИС на базе концепции метаданных и метаклассов;
создание программного средства разработки объектных моделей ГИС;
экспериментальное подтверждение применимости предложенной методики.
Методы исследования основаны на использовании системного и
объектно-ориентированного анализа, объектно-ориентированного
проектирования, теории метаданных и теории моделей. В разработке программного обеспечения использовалась технология объектно-ориентированного программирования.
Научная новизна. Предложен новый подход к процессу разработки геоинформационных систем. Новизна подхода, прежде всего, заключается в использовании настраиваемой объектной модели. В отличие от существующих методик, такой подход обеспечивает:
описание свойств классов объектов предметной области на языке описания метаданных, а не на языке программирования;
единое представление информационных объектов, создаваемых на основе описаний метаклассов, для всех подсистем ГИС, что значительно упрощает их программную архитектуру;
упрощение структуры баз данных информационной подсистемы ГИС за счет хранения метаданных в самих объектах;
упрощение процесса сопровождения ГИС, поскольку снижается вероятность необходимости изменения программного кода и структур баз данных при внесении изменений в иерархию классов предметной области.
Практическая ценность. Теоретические исследования завершены созданием на их основе математического и программного обеспечения компонентов геоинформационной системы, предназначенной для решения задач поиска подвижных объектов, в том числе:
создана настраиваемая объектная модель предметной области ГИС и программное средство визуальной настройки модели;
разработан встроенный язык управления ГИС-объектами SOML и создан интерпретатор этого языка;
разработан протокол обмена компонентами распределенной ГИС на основе сокетов ТСРЛР;
создана подсистема долговременного хранения программных компонентов на базе структурированного хранилища СОМ с
поддержкой транзакций, блокировок и методов оптимизации доступа; создана и активно применяется в интеллектуальной ГИС подсистема моделирования прикладных задач поиска, использующая разработанную объектную модель предметной области. На защиту выносятся следующие результаты:
Методика разработки интеллектуальных ГИС на основе настраиваемой объектной модели предметной области.
Настраиваемая объектная модель предметной области ГИС на основе концепции метаданных.
3. Средство разработки объектных моделей предметной области ГИС.
Апробации работы.
Приведенные в диссертации результаты представлялись автором на VIII Санкт-Петербургской международной конференции "Региональная информатика 2002" (Санкт-Петербург, 25-28 ноября 2002) и международном семинаре IF&GIS «Интеграция информации и геоинформационные системы» (Санкт-Петербург, 17-20 сентября 2003).
Публикации
По теме диссертации опубликовано 7 печатных работ, отражающих основные результаты выполненных исследований.
Структура и объем работы.
Диссертационная работа состоит из введения, 4 глав, заключения и списка литературы, включающего 126 наименований. Общий объем работы составляет 168 страниц, в том числе 24 рисунка и 4 таблицы.
В первой главе приводится подробный анализ возможностей и проблематики современных геоинформационных систем. В результате обзора и классификации существующих программных средств ГИС-технологий
рассматривается понятие интеллектуальной ГИС как геоинформационной системы, предназначенной для решения задач моделирования процессов и ситуаций и комплексного анализа разнотипных данных. Далее в главе сформулированы требования, предъявляемые к интеллектуальным ГИС
На основе анализа проблем взаимодействия компонентов распределенных систем обоснована необходимость разработки специализированной технологии взаимодействия компонентов интеллектуальной ГИС.
Во второй главе разрабатывается и анализируется методика создания интеллектуальных ГИС на основе настраиваемой объектной модели предметной области. Для эффективной поддержки этой модели предлагаемая методика также включает в себя:
выбор технологии долговременного хранения объектов ГИС;
разработку коммуникационной подсистемы.
Доказано, что предлагаемая методика разработки позволяет снизить трудоемкость разработки сложных программных систем, имеющих большое количество классов объектов, состояние которых необходимо сохранять в базе данных
Третья глава посвящена реализации настраиваемой объектной модели предметной области интеллектуальной ГИС. В рамках предложенной модели рассматривается разработка встроенного языка управления ГИС-объектами и методика реализации интерпретатора этого языка. Приводятся сравнительные характеристики быстродействия разработанной модели по сравнению с традиционными объектными подходами.
Четвертая глава описывает разработанное программное средство разработки объектных моделей ГИС. Данное средство обеспечивает поддержку адаптивного жизненного цикла процесса разработки, благодаря чему сокращаются сроки и повышается качество разработки ГИС.
Обзор существующих программных средств создания ГИС-приложений
Рассмотрим более подробно инструментальные средства разработки ГИС-проектов и приложений в оболочках наиболее известных геоннформационных систем - лидеров мирового и Российского рынка ГИС-технологий и попытаемся выделить наиболее важные критерии сравнения современных ГИС-продуктов.
MGE (Modular GIS Environment) - модульная ГИС-среда, производимая компанией INTERGRAPH. MGE - это полнофункциональная инструментальная ГИС, насчитывающая в своём составе более 60 модулей различного функционального назначения, и одновременно - сквозная производственная картографическая система. Спектр функциональности модулей MGE невероятно широк и незаменим для тех приложений, где продукты другого класса не могут решить всех проблем.
В качестве базового графического ядра в системе MGE используется векторный редактор корпорации Beantly - Microstation J (SE). Все приложения MGE являются программными надстройками над MicroStation, который представляет собой мощный многофункциональный графический редактор и имеет развитые средства создания собственных программных приложений.
В основе программных средств создания и манипулирования базами картографических данных MGE лежит традиционная для такого уровня ГИС модель линейно-узловой топологии пространственных объектов с традиционной послойной организацией и связанная с ними описательная или атрибутивная информация, хранимая во внешней СУБД.
К прикладным программным средствам общего назначения относятся программные модули, решающие такие задачи, как пространственный анализ данных, обработка изображений, трехмерное моделирование и анализ местности и т. п. Среди всей совокупности продуктов MGE три модуля являются базовыми, поскольку содержат основные функции создания и сопровождения ГИС проекта. Это MGE Basic Nucleus - ядро системы, MGE Basic Administrator -основной администратор и MGE Base Mapper - базовый картографический модуль. Наличие этих продуктов в системе необходимо практически при любой конфигурации рабочих мест. Набор дополнительных приложений MGE в системе зависит от конкретной решаемой задачи.
Взаимодействие системы с табличной базой данных обеспечивает модуль RIS - Relational Interface System, входящий в стандартную поставку базовых продуктов MGE. MGE может работать с такими известными промышленными СУБД как SYBASE, ORACLE, INFORMIX, INGRES, MS SQL, DB2 и т.д. Кроме того, версии (7.0 и выше) продуктов MGE имеют поддержку механизма ODBC для связи с реляционными базами данных.
MicroStation GeoGraphics позиционируется на рынке как самостоятельная геоинформационная система, но ее скорее следует рассматривать как инструментарий для разработки собственных приложений, поскольку каждый проект требует индивидуального подхода в плане настроек интерфейса, создания макросов и дополнительных модулей. Мощные инструментальные средства позволяют разрабатывать любые рабочие места в соответствии с идеологией проекта. Главное достоинство GeoGraphics заключается в том, что это интеграционная ГИС-платформа высокого уровня. То есть все многообразие инструментов MicroStation остается доступным пользователю GeoGraphics как разработчику, и, кроме этого, предоставляется возможность создания собственных специализированных приложений на базе GeoGraphics.
Интерфейс MicroStation GeoGraphics можно настроить в соответствии с назначением каждого рабочего места. В системе разработаны очень мощные инструменты автоматического отслеживания и исправления топологических ошибок типа двойных, пересекающихся, частично совпадающих, разорванных линий и т.д.
Геоинформационная система Maplnfo была разработана в конце 80-х годов фирмой Mapping Information Systems Corporation (USA). ГИС Maplnfo работает на платформах PC (Windows З.х/95/98/NT), PowerPC (MacOS), Alpha, RISC (Unix).
Пакет Maplnfo специально спроектирован для обработки и анализа информации, имеющей адресную или пространственную привязку. Встроенный мощный язык запросов SQL ММ, благодаря географическому расширению, позволяет организовать выборки с учетом пространственных отношений объектов, таких как удаленность, вложенность, перекрытия, пересечения, площади и т.п. Запросы к базе данных можно сохранять в виде шаблонов для многократного использования. В Maplnfo имеется возможность поиска и нанесения объектов на карту по координатам, адресу или системе индексов.
В Maplnfo можно работать с данными в форматах Excel, Access, xBASE, Lotus 1-2-3 и текстовом. Конвертация файлов данных не требуется. Maplnfo -открытая система. Язык программирования MapBasic позволяет создавать на базе Maplnfo собственные ГИС.
Проблемы взаимодействия компонентов в распределенной ГИС
В состав брокера ORB обычно входят библиотека, которая связывается с каждым процессом CORBA, и процесс-"демон", участвующий в формировании соединения, но не в других коммуникационных операциях. Процессы узла-клиента осуществляют вызовы объектов, принадлежащих процессам сервера, причем система обладает гибкостью, выражающейся в том, что серверы также могут вызывать объекты (т. е. вести себя подобно клиентам), а клиенты - сами содержать объекты.
Брокеры ORB поддерживают и другие функциональные возможности. Например, интерфейс динамической активизации (Dynamic Invocation Interface, DII) и интерфейс динамических схем (Dynamic Skeleton Interface, DSI) позволяют производить доступ к объектам, не используя заглушки и структуры (skeletons), специфические для конкретных типов объектов.
Каждый объект CORBA снабжается интерфейсом, определенным на языке описания интерфейса (Interface Definition Language). В основе его лежит простая объектная модель [20]. IDL играет роль общепонятного рабочего языка, совместно используемого различными программами и системами. Брокер ORB передает объекту относящиеся к нему запросы и выполняет все необходимые процедуры преобразования между средой вызывающей программы и средой объекта.
Протокол Internet InterORB Protocol (ПОР) должен использоваться брокерами ORB для поддержания взаимодействия в сети Internet. Стандартный пакет ПОР включает идентификатор требуемого объекта, обозначение вызываемой операции и передаваемые объекту параметры.
Архитектурой CORBA определены различные службы (сервисы) , расширяющие круг основных возможностей брокеров ORB. Некоторые из этих служб функционируют в качестве серверов поверх ORB, другие же следует встраивать в ORB, по крайней мере частично.
Сервисы CORBA намного облегчают жизнь разработчикам приложений, потому как решают множество типичных задач, с которыми сталкиваются разработчики при создании среды взаимодействия между компонентами приложений [22].
Модель распределенных объектов DCOM (Distributed Component Object Model) была разработана корпорацией Microsoft на основе созданных ранее и весьма популярных технологий этой компании - OLE, СОМ и ActiveX.
В рамках модели СОМ был предложен стандарт двоичного интерфейса, позволившего организовывать службы (в виде динамически компонуемых библиотек или приложений) на разных языках программирования. Однако возможности этой модели существенно ограничивались тем, что она не поддерживала распределенные среды. В модели DCOM этот недостаток устранен: клиентам разрешено обращаться к имеющимся службам с удаленных компьютеров через сеть. Технологии OLE сравнительно недавно были переименованы в ActiveX, а термин OLE вновь обрел свой первозданный смысл.
Модель DCOM изначально разрабатывалась с целью обеспечить возможность интеграции приложений. Идея поддержки распределенной обработки появилась позднее. Объект DCOM предоставляет сервис посредством одного или нескольких отличающихся друг от друга интерфейсов. Он может использовать все свои интерфейсы самостоятельно, а может прибегнуть к так называемому методу агрегирования и передать один или несколько интерфейсов в распоряжение других объектов DCOM. Агрегирование позволяет строить приложение из повторно используемых компонентов DCOM.
Другое расхождение с классическими объектно-ориентированными моделями выражается в том, что DCOM не поддерживает полиморфизм. Сторонники DCOM считают, что такая поддержка является излишней в модели, главное предназначение которой - построение приложений из двоичных компонентов. Заметим, однако, что DCOM не накладывает никаких ограничений на использование в процессе разработки языка, поддерживающего полиморфизм.
Узел-клиент может запросить объект DCOM (используя стандартные методы интерфейсов, реализуемые всеми объектами DCOM) через какой-либо конкретный интерфейс, идентифицируемый уникальным номером (UUID). Интерфейс считается постоянным: после того как он опубликован, его не разрешается изменять. Добавление новых функций в объект DCOM может производиться только путем создания новых интерфейсов.
Хотя между технологиями CORBA и DCOM имеются существенные различия, обе они поддерживают интеграцию компонентов. Так, DCOM позволяет преодолевать ограничения, связанные с сетевой средой, языком программирования, унаследованным программным обеспечением и парадигмой. Минусы этой модели связаны с тем, что она не является открытым стандартом.
Особенность технологии Web- сервисов состоит в том, что она предполагает взаимодействие распределенных компонентов путем обмена XML-сообщениями при помощи протокола SOAP. При этом интерфейсы определяются с помощью языка WSDL (Web Services Description Language), a UDDI (Universal Description, Discovery and Integration предоставляет службу динамического каталога для компонентов, предоставляющих свои услуги, и для компонентов, которые эти услуги используют.
Web-сервисы базируются на стандартах XML, SOAP и HTTP. XML проектировался в основном для того, чтобы снабдить разработчиков инструментарием, упрощающим создание специализированных форматов описания данных, что было весьма актуально, учитывая рост объемов и сложности данных. Все чаще стали возникать задачи, в которых программистам требовалось представлять данные в хорошо структурированной форме. Часто возникали задачи экспорта данных в некоем формате, который можно было бы в перспективе сравнительно легко понимать и обрабатывать. Язык XML, позволив это, предоставил возможность проверки структуры данных, снизив риск обмена поврежденными или неправильно структурированными данными. Это достигается путем задания корректной структуры XML-документа в виде определения Data Description Definition (DTD).
Однако DTD не решает проблемы типизации данных; например, можно определить необходимость наличия того или иного элемента в XML-документе, но нельзя задать его тип и граничные значения. Эти ограничения снимает язык XML Schema, позволяющий задавать корректную структуру XML-документа, учитывая при этом типы и допустимые значения элементов.
Разработка настраиваемой объектной модели предметной области ГИС
В рамках объектной модели ПО конкретная реализация программных объектов зачастую может иметь в различных аспектах ГИС общие свойства, но разное поведение, что повлечет отнесение таких объектов к различным классам.
Спецификации классов и отношений между ними, как правило, отображаются на структуру базы данных, которая используется для хранения текущего состояния объектов. В результате любое изменение в библиотеке классов влечет за собой изменение в структуре базы данных, что, в свою очередь, требует изменения модулей и компонентов программной системы. Эти факторы сильно затрудняют сопровождение и дальнейшее развитие программной системы, ее быструю адаптацию к изменению требований. Устранение вышеуказанных недостатков возможно с использованием концепции метаданных[48] и, в частности, ее реализации в виде двухуровневой модели.
Метаданные - это данные, описывающие организацию других данных. Например, совокупность значений свойств программного объекта описывает его текущее состояние и является конкретными данными. Прежде, чем мы сможем создать программный объект некоторого класса, мы должны описать данный класс объектов, то есть привести описание того, сколько свойств будут иметь объекты данного класса, каких типов должны иметь эти свойства, какой у них возможен диапазон значений и т.д. Таким образом, спецификация класса является метаданными программных объектов.
Следующим уровнем модели метаданных являются метаклассы. Метаклассы описывают и хранят информацию о классах. Метаклассы содержат информацию об имени класса, совокупности его свойств, типах каждого из свойств и т.д. Метаклассы используются для описания классов и отношений между ними в моделях программных систем. В большинстве объектно-ориентированных языков программирования поддерживается только уровень метаданных, то есть описание классов объектов. Создание нового класса объектов возможно лишь путем его описания в исходном модуле программы программистом и последующей перекомпиляцией программного проекта.
Если реализовать в программной системе уровень метаклассов, то классы для такой программной системы становятся информационными объектами и переносятся из разряда программного кода в разряд данных, которыми способна манипулировать данная система. Такой подход предоставляет следующие преимущества: классы объектов предметной области и отношения между ними описываются не как программный код, а как данные, что значительно повышает гибкость программной системы и возможности ее адаптации к изменению требований; изменение характеристик класса не влечет за собой необходимости изменения программного кода системы, вследствие чего упрощается процесс сопровождения библиотек классов; библиотеки классов могут храниться в базе данных, при этом структура базы данных системы становится проще и не требует изменений при изменении описания классов. При традиционных методиках разработки программных систем с использованием объектно-ориентированной технологии [49, 50, 51] на этапе анализа выделяются совокупность объектов предметной области, которые являются существенными для разрабатываемой программной системы (см. рис.2.3). Далее производится выделение свойств объектов и элементов их поведения. По основанию общности свойств и поведения объекты классифицируются, то есть относятся к некоторому классу объектов предметной области. Между классами объектов могут быть установлены отношения обобщения, ассоциации и зависимости. Частным случаем отношения ассоциации являются отношения агрегации и композитной агрегации [51]. В дальнейшем на этапе проектирования производится детальное специфицирование интерфейсов классов. Интерфейс класса определяет количество и типы атрибутов, а так же подробные сигнатуры методов, которые используются объектами других классов для доступа к значениям свойств объектов данного класса и управления его поведением. На этапе реализации, полученные на этапе проектирования спецификации классов, распределяются по программным компонентам и описываются на выбранном объектно-ориентированном языке программирования. При этом уточняется состав атрибутов и методов классов, которые не входят в интерфейсную часть. После этого осуществляется компиляция и сборка программных компонентов, отладка, тестирование и предъявление полученного программного продукта заказчику. Все этапы итеративно повторяются до тех пор, пока программная система не будет полностью удовлетворять требованиям заказчика. Для повторного использования программного кода, классы, как правило, сводятся в библиотеки классов [52]. Таким образом, программная система, разработанная с использованием традиционной объектно-ориентированной технологии, представляет собой совокупность взаимосвязанных программных компонентов, которые реализуют классы и объекты предметной области. Как было показано выше, традиционная методика описания программных систем имеет ряд недостатков при разработке интеллектуальных ГИС. Кроме того, с помощью традиционной методики практически невозможно обеспечить единство представления объектов для всех подсистем распределенных ГИС.
Методика реализации интерпретатора встроенного языка
При разработке любой объектно-ориентированной системы важным является вопрос выбора языка управления или создания и сопровождения объектов в информационной базе. В общем случае, структура объекта находится в состоянии непрерывного изменения, связанного как с физической стороной его существования, так и с изменением целей, задач и "точки взгляда" на этот объект со стороны геоинформационной системы. Требованием к языку управления в данном случае является даже не столько его объектная ориентированность, сколько автоматическая адаптация построений на данном языке к изменяющейся структуре объекта.
Разработчику прикладных задач необходим полный и удобный доступ ко всем полям ГИС-объектов, а также средство для вызова методов объектов и возможность определения некоторых сценариев моделирования. Для этой цели объектная модель ПО ГИС включает в себя интерпретатор встроенного языка, позволяющий оперировать любым объектом темы при помощи скриптов.
Под скриптом понимается текст программы (сценария) на языке интерпретатора. Интерпретатор встроен в ядро системы и позволяет выполнять определенный набор действий над объектами, вычислять сложные выражения и запускать сценарии.
Базовый вариант языка интерпретатора предусматривает лишь минимальные средства языка программирования (так, в нем отсутствуют операторы перехода, цикла, условия и т.п.), но он легко может быть расширен до возможности полноценной поддержки любого из процедурных языков программирования. Например, в распределенной ГИС DMView, созданной при помощи предлагаемой методики разработки, подсистема моделирования на основе сценариев использует в качестве языка интерпретатора подмножество языка Pascal. Следует отметить, что язык управления объектами не предназначен для реализации объектных методов, которые, как правило, пишутся на Delphi или C++ и компилируются в подгружаемые модули. Область применения этого языка охватывает следующие программные задачи: вызов методов объектов из прикладных задач ГИС; создание пользовательских процедур инициализации объектов (конструкторы); создание пользовательских процедур, вызываемых при изменении значения поля объекта. Как правило, во всех этих случаях функциональность скриптов состоит в изменении значений полей и вызове заранее определенных методов объектов.
Процесс интерпретации скриптов состоит из отдельных фаз, связанных между собой через структуры данных в памяти. Каждая фаза транслятора получает набор данных от предыдущей фазы, обрабатывает его (линейным или каким-либо другим, например, рекурсивным алгоритмом), создает внутренние таблицы данных и по ним формирует выходной набор с данными для следующей фазы.
Фазы трансляции вызывают одна другую в процессе обработки соответствующих языковых единиц. Синтаксический анализ является центральным в такой структуре. То есть, основной программой интерпретатора является синтаксический анализатор, который при анализе структурной единицы языка вызывает лексический анализатор для чтения очередной лексической компоненты (идентификатора, константы), а по завершении разбора - семантическую процедуру или процедуру непосредственной интерпретации. Обобщенная структура интерпретатора и основные фазы трансляции показаны на рис. 3.7.
На фазе лексического анализа (ЛА) входной скрипт, представляющий собой поток символов, разбивается на лексемы-слова в соответствии с определениями языка. В базовом варианте интерпретатора SOML лексический анализатор выполнен в виде конечного автомата. Как известно, конечным автоматом является система, которая в каждый момент времени может находится в одном из конечного множества заданных состояний. Каждый шаг (переключение) автомата состоит в том, что при нахождении в определенном состоянии при поступлении на вход одного из множества входных сигналов (воздействий) он переходит в однозначно определенное состояние и вырабатывает определенное выходное воздействие.
Лексический анализатор может работать в двух основных режимах: либо как подпрограмма, вызываемая синтаксическим анализатором за очередной лексемой, либо как полный проход, результатом которого является файл лексем. В процессе выделения лексем ЛА может как самостоятельно строить таблицы имен и констант, так и выдавать значения для каждой лексемы при очередном обращении к нему. В этом случае таблица имен строится в последующих фазах (например, в процессе синтаксического анализа). На этапе ЛА обнаруживаются некоторые (простейшие) ошибки (недопустимые символы, неправильная запись чисел, идентификаторов и др.).
Основная задача синтаксического анализа - разбор структуры программы. Как правило, под структурой понимается дерево, соответствующее разбору в контекстно-свободной грамматике языка. Здесь может использоваться либо 1Х(1)-анализ (и его вариант - рекурсивный спуск), либо Ы1(1)-анализ и его варианты (LR(0), SLR(1), LALR(1) и другие). В базовом варианте интерпретатора SOML используется рекурсивный спуск. Результатом синтаксического анализа является синтаксическое дерево со ссылками на таблицу имен. В процессе синтаксического анализа также обнаруживаются ошибки, связанные со структурой программы.
На этапе контекстного анализа выявляются зависимости между частями программы, которые не могут быть описаны контекстно-свободным синтаксисом. Это в основном связи "описание-использование", в частности анализ типов объектов, анализ областей видимости, соответствие параметров, метки и другие. В базовом варианте интерпретатора SOML эта стадия не реализована, поскольку вся информация о типах уже содержится в полях ГИС-объекта, а возможность создания каких-либо переменных помимо полей объекта в SOML отсутствует. Расширения языка могут включать этап контекстного анализа, модифицирующий или дополняющий синтаксическое дерево.
