Графический редактор объектных моделей для задач автоматического анализа текста

Вид материалаДоклад

Содержание


Взаимодействие редактора и приложений
Рис. 1 Схема взаимодействия конструктора с приложениями.
Рис. 2 Фрагмент XML описания визуализации объектов.
Новые возможности редактора
Рис. 2 Объект myObj1 в "свернутом" a) и "развернутом" b) видах
Применение редактора к задачам объектного моделирования в лингвистике.
Список литературы
Подобный материал:

Графический редактор объектных моделей для задач автоматического анализа текста1

А.В. Колесников, М.Е. Епифанов

Введение


В докладе на конференцию КИИ 2004 [1] была представлена первая версия графического конструктора объектных моделей на основе Microsoft Visio. Этот инструмент позволял строить изображения объектных моделей (точнее, изображения фрагментов больших, т.е. состоящих из большого количества объектов, моделей, а изображения небольших моделей – целиком) в виде диаграмм MS Visio и сохранять их в документах специального XML языка. Последние могли передаваться в приложения, поддерживающие работу с соответствующими им моделями. Таким образом, связь между графическим конструктором и интерпретирующими объектные модели приложениями была «однонаправленной». Функциональность описываемой в данной работе настоящей версии рассматриваемого инструмента доведена до уровня, когда он становится полноценным редактором, позволяющим просматривать и изменять фрагменты уже имеющихся моделей, а не только рисовать новые. Некоторые новые возможности редактора облегчают работу с достаточно большими фрагментами.

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

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

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

Взаимодействие редактора и приложений


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

В MS Visio пользователь рисует свои диаграммы на основе некоторого шаблона (stencil), выбранного им из имеющихся. Такой шаблон предоставляет пользователю свой, связанный с определенной «темой», набор конструктивных графических элементов, которые могут обладать своим поведением. Сам шаблон может быть также наделен некоторой специфической функциональностью3. Часть шаблонов входит в комплект поставки MS Visio, но они могут также добавляться независимыми разработчиками.

Общая функциональность графического конструктора, не зависящая от различных объектных моделей, реализована в виде единственного подобного шаблона. Для настройки на рисование объектов из конкретной библиотеки типов служит файл XML описания визуализации объектов. Такой файл содержит сведения о структуре объектов и о способе их отображения в редакторе. Этот файл ассоциируется с шаблоном и загружается вместе с ним (рис. 1). При разработке «уникального» графического интерфейса для моделирования на основе новой объектной библиотеки, программисту требуется только разработать такой файл настройки и его XSD схему. Затем он просто создает новый шаблон редактора копированием любого уже имеющегося и изменяет в нем путь – к новому файлу настройки.



Рис. 1 Схема взаимодействия конструктора с приложениями.

В процессе редактирования визуальные образы объектов заполняются данными, между объектами устанавливаются связи. Результат своей работы пользователь конструктора может сохранить либо в виде диаграммы Visio, т.е. в файле с расширением vsd, либо в XML файле описания структуры объектов, представляющем разработанную объектную модель (или её часть) в специально разработанном для этого XML языке. Vsd файл можно использовать лишь для дальнейшего конструирования модели в редакторе, в то время как XML представление может быть передано соответствующему приложению для изменения состояния объектной модели (рис. 1). Ясно, что такое приложение должно поддерживать API интерпретации XML языка описания объектной модели. Фрагменты модели для редактирования «поступают» от соответствующего приложения также в виде подобных XML документов (рис. 1).

Форматы XML файлов настройки и собственно представления модели абстрагированы от содержания библиотек типов.



Рис. 2 Фрагмент XML описания визуализации объектов.

Например, на рис. 2 показано описание структуры и способа изображения объектов определенного типа в редакторе. Указывается, что объекты типа dswTextFileLines имеют фиксированную структуру из нескольких полей (т.е., скорее всего реализованы в «ООП с классами»). Описываются типы значений полей данных и то, как эти поля предъявляются пользователю для редактирования. Так, поле IOmode здесь может иметь только одно из трех значений («ForReading», …) типа «строка», причем пользователь будет выбирать их из поля со списком (…valueControl=“combo”). Похожим, но несколько более сложным образом описывается случай, когда значением поля могут быть объекты (точнее, ссылки на них).

На рис. 3 показано представление объекта того же типа dswTextFileLines в XML файле, полученном как результат работы в редакторе. Видно, что это описание дается «в терминах» объектов, их полей данных, значений полей и т.п. и, тем самым, является универсальным.



Рис. 1 Фрагмент объектной модели, сохраненной в виде XML-файла

Новые возможности редактора


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

При работе с содержащими большое число объектов диаграммами желательно подавлять несущественные в данный момент детали. Разработанный в настоящей версии дизайн визуализации объектов и поддерживающие его механизмы позволяют показывать объекты как в скрытом виде, т.е. в виде одной лишь иконки узла сети модели, так и в развернутом виде, когда видно содержимое полей объекта (рис. 4). В настоящее время разрабатываются такие механизмы перестройки диаграммы при смещении объектов во время сжатия/развертывания некоторого объекта u, при которых необходимое смещение выполнялось бы только для сравнительно близких к u объектов и «затухало» бы по мере удаления от u. Это сделает визуализацию более удобной и облегчит обзор больших диаграмм. Исследуется (с целью спецификации этой задачи) также возможность сокрытия подробной информации о группе объектов на диаграмме, рассматриваемых как одно целое.

a) b)

Рис. 2 Объект myObj1 в "свернутом" a) и "развернутом" b) видах

На рис. 4 стрелки, показывающие ссылки в полях объекта myObj1 на объекты myObj2 и myObj3 пересекаются. Объектные модели удобно рассматривать как орграфы, в которых вершины соответствуют объектам, а дуги – ссылкам из полей объектов на другие объекты (т.е. значения таких полей – объекты). Редактор ориентирован на иерархические модели, т.е. деревья или ациклические сети. Ясно, что «произвольное» пересечение дуг для моделей с большим числом объектов и связям между ними существенно затрудняет их восприятие при визуализации. В то же время, в случае сети, орграф модели «не обязан» быть планарным. В настоящее время разрабатывается возможность показывать пользователю модель в «приближенном» к плоскому графу виде, так чтобы по возможности уменьшить количество пересечений стрелок.

Применение редактора к задачам объектного моделирования в лингвистике.


Как показано выше, редактор может использоваться как графический интерфейс для работы с любыми иерархическими моделями, он является универсальным средством проектирования объектных моделей в любой области знаний. Конкретизация области его применения в заголовке данной работы объясняется лишь тем, что нами он пока используется только в рамках проекта по объектному моделированию в лингвистике, в настоящее время разрабатываемого в Отделении интеллектуальных систем (в гуманитарной сфере) Института лингвистики РГГУ, как один из инструментов для построения:
  • объектной модели лексики языка флективного типа (строится для русского и латинского языков), основанной на синтезе лингвистических единиц [2, 3];
  • объектной модели морфологического анализа текстов на языке флективного типа (строится для русского языка) [3];
  • объектной модели так называемых лингвистических алгоритмов, как части объектной модели поверхностно синтаксического анализа текстов на русском языке [4, 5].

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

Применение редактора к описанию лингвистических алгоритмов в объектном моделировании поверхностно синтаксического анализа русского предложения потребовало дополнительной реализации особой функциональности. Поля данных объектов – узлов алгоритма могут иметь достаточно большое по объему содержимое (коды произвольной длины в синтаксисе языка Лисп), что поставило перед конструктором задачу удобной графической реализации их просмотра и редактирования. Очевидно, что диаграмма не должна быть «загружена» подробной информацией о содержимом всех полей данных, потому что это сделало бы её плохо читаемой. Поэтому, был реализован механизм сходный механизму скрытия полной информации об объекте (см. выше), позволяющий скрывать и показывать содержимое полей, «сохраняющих» большие тексты. Редактирование таких текстов происходит с использованием отдельного элемента управления.

Список литературы

  1. Ершова Е.С., Епифанов М.Е. Графический конструктор структур объектов как интерфейс инструментальной объектной среды // Девятая национальная конференция по искусственному интеллекту с международным участием КИИ 2004: Труды конференции. Т.2. – М.: Физматлит, 2004, с.498 507.
  2. Ивличева О.О. Эксперименты с представлением некоторых сложно устроенных составных лингвистических единиц в объектной модели многофункциональных электронных словарей. // Девятая национальная конференция по искусственному интеллекту с международным участием КИИ 2004: Труды конференции. Т.2. – М.: Физматлит, 2004, с.525 534.
  3. Алферова М.С., Епифанов М.Е., Лахути Д.Г. Преобразование объектной модели лексики языка в объектную модель для морфологического анализа// Девятая национальная конференция по искусственному интеллекту с международным участием КИИ 2004: Труды конференции. Т.2. – М.: Физматлит, 2004, с.452 462.
  4. Баталина А.М., Айриян Г.Ю., Епифанов М.Е., Кобзарева Т.Ю., Лахути Д.Г. Автоматизация отладки алгоритмов поверхностно синтаксического анализа. // Компьютерная лингвистика и интеллектуальные технологии: Труды Международной конференции Диалог'2005(Звенигород, 1-6 июня 2005 г.) – М.: Наука, с.45 50.
  5. Баталина А.М., Епифанов М.Е. Объектная модель поверхностно синтаксического анализа. // Десятая национальная конференция по искусственному интеллекту с международным участием КИИ-2006: Труды конференции. Т.2. – М.: Физматлит, 2006, с. 598 606.

1 Доклад подготовлен при частичной поддержке РФФИ (грант 06-06-80434).

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

3 Аналогичным образом документы MS Word строятся на основе представленных в виде dot файлов шаблонов (templates), это общий подход Microsoft к реализации подобных приложений.