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

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ В ЗАДАЧАХ ДИНАМИКИ И УПРАВЛЕНИЯ

угольника неравенство | ищ |< Н нарушается, и скользящий режим по прямой х + ах = 0 не существует. Центр эллипса для области х > 0, х + ах < 0 расположен слева от начала координат

УР Н

(точка Ь =---). Это приводит к тому, что

к к

некоторые траектории из указанной области могут приходить на отрезок застоя [—Ь, Ь] . Скользящий режим реализуется только на отрезках прямой линии х + ах = 0 , расположенных внутри большого и вне маленького прямоугольника, и прекращается

в вершине маленького прямоугольника.

Рис. 2. Верхняя фазовая полуплоскость при выполнении условия Н < УР

Работа выполнена при финансовой поддержке СО РАН (интеграционный проект № 85).

БИБЛИОГРАФИЯ

1. Филиппов, А.Ф. Дифференциальные уравнения с разрывной правой частью / А.Ф. Филиппов. - М.: Наука, 1985.

2. Айзерман, М.А. Основы теории разрывных систем. I, II / М.А. Айзерман, Е.С. Пятницкий // АиТ. - 1974. - № 7. - С. 33-47; № 8. - С. 3961.

3. Уткин, В.И. Скользящие режимы в задачах оптимизации и управления / В.И. Уткин. - М.: Наука, 1981.

4. Пятницкий, Е.С. Синтез иерархических систем управления механическими и электромеханическими объектами на принципе декомпозиции. I, II / Е.С. Пятницкий // АиТ. - 1989. - № 1. - С. 87-98; № 2. - С. 57-71.

5. Финогенко, И.А. О принципе декомпозиции для механических систем с сухим трением / И.А. Финогенко // Современные технологии. Системный анализ. Моделирование. - 2008. -№ 3(19). - С. 66-70.

6. Обуховский, В.В. Введение в теорию многозначных отображений и дифференциальных включений / В.В. Обуховский, Ю.Г. Борисович, Б. Д. Гельман, А. Д. Мышкис. - М.: Ком-Книга, 2005.

Черкашин Е.А., Ипатов С.А. УДК 004.4'242

логический подход к обработке

uml-моделей информационных

систем

Введение. В настоящее время при разработке сложных информационных систем популярно визуальное проектирование с использованием языка UML (Unified Modeling Language). Одним из обменных форматов представления UML-моделей является базирующийся на стандарте XML (Extensible Markup Language) [1] формат XMI (XML Metadata Interchange) [2]. Стандарт XML является одной из популярных технологий, используемых для представления информации, в частности, для хранения документов и обмена информацией между приложениями, а также для передачи информации, например, XML-RPC (XML Remote Procedure Call) [3]. Основными причинами

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

Существует ряд подходов к решению задачи трансляции и обработки XML-документов. Для императивных языков программирования консорциумом W3C разработаны стандартизованные технологии SAX (Simple API for XML) и DOM (Document Object Model). Технология SAX представляет разработчику (программисту) событий-

ный механизм конструирования/обработки XML-документа, основанный на функциях обратного вызова (callback functions). Эта технология позволяет программисту самостоятельно создавать структуры данных, в которые преобразуется исходный XML-документ. Кроме того, если предположить, что XML используется как обменный формат или формат для хранения данных, то разработчику необходимо реализовать преобразования структур данных в памяти ЭВМ в XML-формат самостоятельно. Технология DOM наоборот предлагает программисту использовать стандартную древовидную структуру исходного XML-документа (DOM-дерево) в качестве той структуры данных, которая непосредственно обрабатывается программой. Обработка этой древовидной структуры осуществляется при помощи API-функций, результат сериализуется (serialization) в новый XML-документ. Модель DOM практична, если объем изменений, вносимых в DOM-дерево, значительно меньше объема самого DOM-дерева. Примером такой обработки является технология AJAX (Asynchronous Javascript and XML), обеспечивающая повышение интерактивности статических HTML-документов в браузерах.

Другим набирающим популярность подходом выступает технология XSLT (Extensible

нента nsIXSLTProcessor, доступная в скриптах JavaScript и при отрисовке (rendering) загружаемых из Интернет XML-документов. Ключевым понятием XSLT является таблица стилей трансформации, состоящая из набора шаблонов. Шаблоны представляют собой правила, описывающие процесс трансформации узлов исходного дерева. Процесс трансформации рассматривается как процедура сравнения с некоторым шаблоном и генерирования по этому шаблону части дерева — результата трансформации.

В процессе трансформации доступ к произвольному узлу исходного дерева XML осуществляется при помощи специализированного языка XPath 1.0 [6]. Кроме собственно адресации узлов дерева XPath обладает также функциями преобразования строк, чисел и булевых значений, что позволяет вычислять значения на основании содержания XML-документа.

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

XML

XML-дсрсво в виде фактов

Правила Ппаиила

трансформации

Рис. 1. Схема трансформации XML-документа с использованием процессора XSLT

Stylesheet Language Transformations) [4] (рис. 1). XSLT — это специализированный декларативный язык программирования, разработанный консорциумом W3C и основанный на стандарте XML. Подход позволяет для своего класса задач осуществлять преобразование одного XML-документа в другой XML-документ или текст только по XLST-описанию без дополнительной реализации каких-либо программ трансляции. Процедуры XSLT-трансформации представляются в виде отдельных утилит, например, xsltproc в библиотеке libxml2 [5], либо компонентов систем, например, в web-браузере Mozilla реализована компо-

Резупьтирующи? документ

Рис. 2. Схема трансформации XMI-документа

1. Общая схема процедуры трансформации (рис. 2). Преобразование XML-документа осуществляется поэтапно:

1) трансляция исходного текста в DOM-дерево;

2) преобразование DOM-дерева в набор фактов

языка Prolog. Каждому узлу дерева в зависимости от типа сопоставляется некоторый набор фактов Prolog. В одном из вариантов это преобразование осуществляется формально, т.е. преобразуется древовидное DOM-

представление документа в набор фактов, строго соответствующий этому дереву. С дру-

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ В ЗАДАЧАХ ДИНАМИКИ И УПРАВЛЕНИЯ

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

3) запуск сценария основной обработки, представ-

ляющего собой логический вывод заданного набора целей программы Prolog;

4) генерирование выходной структуры данных, в

том числе при помощи набора текстовых шаблонов.

Рассмотрим использование предлагаемого подхода на примере решения задачи генерирования каркаса исходного кода программной системы по ее формальному описанию в рамках технологии MDA.

MDA (Model Driven Architecture) — подход к проектированию программных систем (ПС), предложенный в 2001 году консорциумом OMG (Object Management Group) и являющийся дальнейшим развитием идеи визуального проектирования. Как и множество других технологий, MDA преследует три основные цели — это повышение качества программного обеспечения за счет высокой переносимости между программно-аппаратной платформы (ПАП), открытость к взаимодействию с другими системами и повторное использование формализованных знаний разработчиков, в частности, представленных в виде исходного кода компонент программных систем. Формально MDA преследует цель отделить спецификацию функций ПС от способа реализации этих функций на различных ПАП. MDA обеспечивает реализацию следующих идей:

• ПС моделируется в виде, не зависящем от ПАП, на которой она будет функционировать;

• ПАП представляется в виде формальной модели, которая обычно представляет собой программную систему трансформации (преобразования) моделей ПС;

• исходная спецификация ПС автоматически трансформируется (преобразуется) в конкретную ПС, каркас ПС или программную библиотеку, реализованные на конкретной

ПАП.

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

Модель ПС, не зависящая от ПАП, в MDA называется моделью, не зависящей от платформы (Platform Independent Model, далее PIM). Модель ПС, учитывающая особенности ПАП в реализации ПС, называется моделью, зависящей от платфор-

мы (Platform Specific Model, далее PSM). Преобразование PIM в PSM осуществляется при помощи формального представления свойств ПАП, модели платформы (Platform Model, далее PM). Как правило, PSM представляет ПС на уровне более абстрактном, чем непосредственно программный код, но позволяющем алгоритмам трансформации генерировать исходный код компонент по текстовым шаблонам. Общая схема трансформации, предложенная в [7] и [8], изображена на рис. 2.

Для трансляции исходной модели, представленной в формате XMI, реализована библиотека YAP, представляющая API библиотеки libxml2 [5] в виде набора соответствующих предикатов. Через этот API Prolog-программа транслирует исходный XMI-файл в структуру, подобную DOM-дереву. Далее эта структура переводится в дерево термов вида xml node(<имя тега>, <тип>, xml ns (<псевдоним>, <URL>), <список атрибутов>, <список дочерних тегов>), где каждый терм представляет один тэг (tag) или текст исходной структуры. Из полученного дерева термов выделяются (распознаются) только необходимые структуры, которые и представляются в виде фактов.

Рассмотрим пример распознавания элемента "класс" диаграммы классов в XMI-документе.

% XMI 2.1 Class

xmi_parse_node(Node):-

% Фаза распознавания структуры поддерева.

% Выделение класса в Диаграмме классов UML. Node=xml_node('packagedElement',

_, _, Attributes, Children), xml_attribute_value(Attributes,

'type', xml_ns('xmi', _),

'uml:Class'), xml_attribute_value(Attributes, 'name',

ClassName), (xml_attribute_value(Attributes,

'visibility', Visibility);

Visibility='public' ), (xml_attribute_value(Attributes,

'isAbstract', Abstract);

Abstract='false'), xmi_id_from_attributes(Attributes, ID),

% Конец фазы распознавания. get_context(OwnerRef), store_object('xmi_classes',

xmi_class(ClassName, ID,

Visibility, Abstract,

OwnerRef), ClassRef), push_context('class', ClassRef), xmi_parse_children_list(Children), pop_context('class', ClassRef). xmi_parse_children_list([]).

Необходимо дать некоторые пояснения. Attributes — список атрибутов тега packagedElement; атрибут type должен быть равен "Class"; если атрибуты visibility и isAbstract не включаются в XMI-файл, то заменяются значениями по умолчанию. Все элементы в UML-диаграмме помечены индивидуальными идентификаторами при помощи атрибута id, правило xmi id from attributes (Attributes, ID) получает этот идентификатор для распознаваемого класса. Правило get context(OwnerRef) получает идентификатор структуры, в которую входит распознаваемый класс; такой структурой для класса выступают "модель", "диаграмма" и "пакет" (package). Предикат push context/2 создает новый контекст, контекст данного класса, в котором будут порождаться факты об атрибутах и методах класса из списка дочерних элементов Children. Предикат store object ('xmi lasses', xmi class(ClassName, ID, Visibility, Abstract, OwnerRef), ClassRef) создает в рабочей памяти факт о существовании данного класса, характеризуемого набором атрибутов. Предикат store bject/3 в третьем аргументе возвращает ссылку на созданный факт, через эту ссылку в YAP-программе осуществляется прямой доступ к факту без обычного перебора фактов классического Prolog.

К моменту начала трансформации в Prolog-программе существуют множество фактов, описывающих структуру UML-диаграммы. Далее пусть, например, необходимо сгенерировать базу данных SQL в виде SQL-скрипта создания базы данных. Пусть также следующий набор фактов содержит список атрибутов и методов одного класса, обозначенного идентификатором 'OrganizationUnit':

xmi_attribute('Name'). xmi_attribute('Address', 'OrganizationUnit'). xmi_attribute('Phone', 'OrganizationUnit'). xmi_attribute('Fax', 'OrganizationUnit').

Правила трансформации представляют собой программу на языке YAP-Prolog (Yet Another Prolog), состоящую из двух частей:

1) правила, описывающие трансформацию исходных фактов в элементы скрипта SQL;

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

Примером вспомогательного высказывания является предикат fields list/2:

fields list(Class, Fields):-

findall(Name, attribute(Name, Class), Fields).

В результате выполнения fields list/2 имена всех полей, для которых существует отношение attribute(Name, Class), помещаются в список Fields, используемый при создании окончательной SQL-команды.

Следующее правило create table/3 отвечает за порождение SQL-команды создания таблицы в базе данных:

create table(Table, Fields, Result):-nonvar(Table), nonvar(Fields), var(Result),

format(' CREATE TABLE '~a' (~a) ~a;', [Table,Fields], Result),!.

В результате выполнения этого предиката переменная Result будет содержать SQL-команду, создающую одну таблицу базы данных:

transform(Model):-nonvar(Model),

create tables(Model, SQLScript), % сгенерировать SQL-скрипт

output(SQLScript). % сохранить полученный скрипт

Сценарий трансформации представляется набором подцелей основной цели transform/1. Правило transform/1 содержит ряд подцелей, одна из них - create tables/2, которая для каждой таблицы, обнаруженной в виде фактов рабочей памяти, вызывает описанную выше подцель create table/3 и объединяет полученные команды в SQL-скрипт. Следующая подцель output/1 сохраняет полученный из transform/1 скрипт в файл.

2. Использование семантической

информации. Помимо метаданных,

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

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ В ЗАДАЧАХ ДИНАМИКИ И УПРАВЛЕНИЯ

характер процесса трансформации. Обработка под управлением семантики проявляется, когда необходимо дифференцировать трансформацию различных элементов диаграммы по какому-либо критерию или специальному признаку. В языке UML существуют механизмы задания семантики элементам — это стереотипы (stereotype), позволяющие создавать новые элементы языка UML, теговые значения (tagged value), которые позволяют создавать новые свойства элементов, и ограничения (constraint), позволяющие формально определять условия или ограничения, которым должен удовлетворять элемент UML-модели.

Рис. 3. Пример PIM

В качестве конкретного примера (рис. 3) можно рассмотреть класс, к которому применен стереотип <<dictionary>>, показывающий, что данный класс является "словарем", т.е. данный класс состоит в отношении один-ко-многим с другими классами, хранящими внешнюю ссылку (...FOREIGN KEY REFERENCES...) на ключевое поле этого словаря. При трансформации PIM в PSM этот стереотип оказывает влияние на структуру конечной PSM, поскольку потребует добавления новых элементов в модель. На рис. 3 изображен процесс трансформации класса PlM в соответствующий класс PSM. А именно, в класс Articles PSM добавлен атрибут id, по которому осуществляется выборка записи в словаре (таблицы), класс помечен стереотипом <<DBTable>>, который означает, что на этапе генерирования исходного кода этот объект трансформируется в таблицу базы данных. Все атрибуты этого класса преобразуются в поля таблицы, для каждого атрибута осуществляется выбор типа данных в языке SQL.

При генерировании таблицы базы данных из класса UML-диаграммы, помеченного

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

значения, не зависящая от семантики атрибута), требуется ли обеспечить производительный поиск по значению этого поля. Последнее свойство реализуется при помощи тегового значения index: если требуется указать, какой метод построения индекса (например, b-tree или hash) следует реализовать, то атрибут помечается тегом index_type. Процедуры трансформации игнорируют семантические данные (теговые значения) об атрибутах, не используемые целевыми ПАП.

generate sql tables params (Class, TableParams):-% свойств таблицы, например, % наличие индекса, при помощи % тегового значения index type, % связанного с классом Class assigned tagged value(Class,

'index type', IndexType), set params('index type',

IndexType, TableParams).

generate_sql_index_list (Class, IndexList):-findall(index elem(index field (Name,Type), Tag), (xmi attribute(Name,Type, ), assigned tagged value(Name, Tag)),IndexList).

generate_sql_fields_list

(Class, FieldList, FieldParams):-findall(Field(Name, Type),

class attribute(Class, Name, Type), FieldsList), findall(Param(Name, Param),

class attribute Param(Class, Name, Type), FieldParams).

generate sql table(Class, SQCLode):-% получение конструктивных

% элементов таблицы

generate sql fields list(Class,

FieldList, FieldsParams), generate sql tables params(Class,

TableParams), generate sql index list(Class,

IndexList), % создание SQL-запросов format_sql_code('CREATE TABLE ~a (~a) ~a;', [Class, TableParams, FieldList, FieldsParams], SQLTableCode), format_sql_code('CREATE INDEX ~a USING ~a ON ~a (~a);',[Class, IndexList, FieldList, FieldsParams], SQLIndexCode), join sql code([SQLTableCode, SQLIndexCode], SQCLode).

generate class code(Class, Code):-Class=xmi class(Name, ID, ,

% Стереотип DBTable показывает, % что класс должен быть % сгенерирован в виде таблицы БД. xmi assigned stereotype(ID, 'DBTable'), generate_sql_table(Class, Code).

Порожденный SQL-скрипт будет иметь вид

CREATE TABLE OranizationUnit( ID INT,

Name VARCHAR(12 8), Address VARCHAR(12 8), Phone VARCHAR(12 8), Fax VARCHAR(12 8),

PRIMARY KEY(ID)) ENGINE = InnoDB;

CREATE TABLE Employee (

FirstName VARCHAR(12 8), MiddleName VARCHAR(12 8), LastName VARCHAR(12 8), Office INT(12), Phone VARCHAR(64), OrganizationUnit_ID INT (12), INDEX organizationunit_ind

(OrganizationUnit ID)

FOREIGN KEY (OrganizationUnit_ID) REFERENCES OranizationUnit(ID) )ENGINE = InnoDB;

Заключение. В работе рассмотрена задача трансформации UML-моделей, управляемая семантикой, хранимой в исходном описании модели и алгоритмах трансформации, с использованием логики первого порядка. Язык логического программирования Prolog

использован для декларативного представления процедур распознавания элементов структуры модели и синтеза новых структур данных. Предложенный подход демонстрирует средство трансформации UML-моделей, представленных в виде XML-документов, а также демонстрирующее декларативный подход к управлению процессом обработки информации XML-документа. Приведен пример трансформации платформо-независимой UML-модели в элементы SQL-скрипта базы данных информационной системы. Формальное описание модели поэтапно обрабатывается модулями трансформации, в результате чего порождается последовательность SQL-команд. Использование логического подхода позволило достаточно лаконично определить процесс трансформации модели программной системы в исходный код ее компонент. Разрабатываемые инструментальные средства синтеза компонент каркаса применяются в цикле разработки информационной системы

"Популяционный раковый регистр" Иркутского онкологического диспансера [8].

Работа выполнена при финансовой поддержке РФФИ, гранты №№ 08-07-00163-a, 07-05-01061-а, 08-07-00163-а, 08-07-98005-р_сибирь_а, 09-07-12017-офи_м и президентской программы «Ведущие научные школы РФ», грант № НШ-1676.2008.1.

БИБЛИОГРАФИЯ

1. W3C Extensible Markup Language [Электронный ресурс] / Консорциум W3C -Режим доступа: http://www.w3.org/XML/, свободный. - Загл. с экрана.

2. OMG XMI Specification [Электронный ресурс] / Консорциум OMG - Режим доступа: http://www. omg .org/technology/documents/forma l/xmi.htm, свободный. - Загл. с экрана.

3. XML-RPC Home Page [Электронный ресурс] / Scripting News, Inc. - Режим доступа: свободный: http://www.xmlrpc.com - Загл. с экрана.

4. XSLT 1.0 W3C Recommendation [Электронный ресурс] / Консорциум W3C - Режим доступа:

МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ В ЗАДАЧАХ ДИНАМИКИ И УПРАВЛЕНИЯ

http://www.w3.org/TR/xslt, свободный. - Загл. с экрана.

5. The XML C parser and toolkit of Gnome [Электронный ресурс] / The GNOME project -Режим доступа: http://xmlsoft.org/, свободный. - Загл. с экрана.

6. XPath Version 1.0. / Консорциум W3C - Режим доступа: http://www.w3 .org/TR/xpath, свободный. - Загл. с экрана.

7. Черкашин, Е.А. Автоматизация синтеза ядра информационной системы с использованием UML-описания / Е.А. Черкашин, Р.К. Федоров, И.В. Бычков, В.В. Парамонов //

9.

Вычислительные технологии. - 2005. - Т. 10. -С. 114-121.

Парамонов, В. В. Реализация и апробирование интеллектного варианта MDA-подхода автоматизации конструирования

информационной системы / В.В. Парамонов // Современные технологии. Системный анализ. Моделирование. Специальный выпуск. - 2008. - С. 69-75.

Братко, И. Алгоритмы искусственного интеллекта на языке PROLOG. 3-е изд. / И. Братко. - М: Изд-во ВИЛЬЯМС - 2004. - 420 с.

Шигаров А.О.

УДК 004.932.2

технология извлечения табличной информации из электронных документов разных форматов

Введение. Для решения многих научных и практических задач требуется извлекать информацию из таблиц, содержащихся в различных документах (например, для поиска информации или анализа данных). Подробно такие задачи рассматриваются в обзоре [1]. Если при этом имеется большое количество таблиц и документов, то ручное извлечение табличной информации (когда оператору приходится визуально обнаруживать каждое табличное значение в документе, а затем вручную вводить его в некоторую форму) может оказаться достаточно трудоемким процессом, связанным с большим количеством возможных ошибок оператора. В данной работе предлагается технология извлечения табличной информации из электронных документов, которая позволяет автоматизировать этот процесс.

В данной технологии решаются следующие задачи извлечения табличной информации:

1) обнаружение таблиц в документах;

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

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

1. Сравнение с существующими методами и системами извлечения табличной информации. Существующие методы и системы решают, как правило, только отдельные задачи извлечения табличной информации, например, только обнаружение таблиц или только сегментацию таблиц. В обзоре [2] из 28 рассматриваемых методов и систем извлечения табличной информации указано всего две системы: авторов Douglas и др. [3] и Hu и др. [4, 5], которые, как и предлагаемая технология, выполняют комплексно все перечисленные задачи. Следует отметить, что система авторов Douglas и др. ориентирована на особенности таблиц, содержащихся в документации строительной промышленности, представленной в виде ASCII-текста. В работах авторов Hu и др. предлагаются методы, ориентированные на ASCII-текст и