CC BY
40
Литература
1. Салибекян С.М., Панфилов П.Б. ОА-архитектура - новый подход к созданию объектных систем // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 73-79 URL: http://objectsystems.ru/files/Object Systems 2011 Proceedings.pdf
2. Jurij Silk, Borut Robic and Theo Ungerer «Asynchrony in parallel computing: From dataflow to multithreading» Institut Jozef Stefan, Technical Report CDS-97-4, September 1997.
3. Головков С.Л., Ефимкин К.Н. Реализация языка программирования для модели вычислений, основанной на принципе потока данных. Москва: ИПМ им. М.В.Келдыша РАН. 2002
4. Салибекян С.М., Панфилов П.Б. Анализ языка с помощью вычислительной системы объектно-атрибутной архитектуры. // Объектные системы - 2012: материал VI Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2012 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. - C. 31-37 URL: http://objectsystems.ru/files/2012/0bject_Systems_2012_Proceedings.pdf
5. Дал У., Дейкстра Э., Хоор К. Структурное программирование. М.: Мир, 1975. — 245 с.
6. Салибекян С.М., Белоусов А.Ю. Сетевая база данных, построенная по объектно-атрибутному принципу. // Объектные системы - 2014 (зимняя сессия): материал IX Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГТУ (НПИ) им. М.И. Платова, 2014. с. 70-76 URL: http://objectsystems.ru/files/2014WS/0bject Systems 2014 Winter session Proceedings.pdf
УДК 681.3
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРЕДСТАВЛЕНИЕ МНОГОУРОВНЕВЫХ
СЕМАНТИЧЕСКИХ МОДЕЛЕЙ4
Грегер Сергей Эдуардович, Уральский федеральный университет имени первого Президента России
Б.Н.Ельцина, Нижнетагильский технологический институт (филиал), Факультет экономики и менеджмента, кафедра информационных технологий, доцент. Россия. Нижний Тагил,
Несмотря на то, что часто предметная область обладает структурой, представленной несколькими логическими уровнями, традиционный подход к моделированию, использующий языки моделирования, основанные на метамоделях, подобных MOF, основан на ограниченном количестве уровней моделирования. Известные технологии метамоделирования, такие как EMF, предоставляют два уровня классификации — метамодель, предоставляющую классы, и модель, содержащую объекты классов метамодели. При этом, как правило, для изменения доступен только уровень модели. Мультиуровневый подход к проектированию не ограничивает число уровней. При наличии нескольких уровней соотношение между классами и объектами требует уточнения.
В [1] предложили методологию разработки программного обеспечения, в дальнейшем отображенную в метамодели IS024744, в которой введены понятия power type и clabject. Целью предложенной методологии является: предоставление возможности построения множества классификационных уровней, объединенных в мультиуровневую модель. Основная проблема, решенная в представленной методологии, состояла в построении унифицированного и адаптируемого метода классификации элементов предметной области. Под унифицированием понимается возможность отображения всех моделей всех уровней
4 Лауреат номинации "Лучший доклад по UML-моделированию". Автор доклада награждается правом бесплатной публикации одного доклада по данной тематике на следующей конференции
71
моделирования через ограниченный набор концепций и символов. Адаптируемость обеспечивается тем, что все концепты моделей всех уровней представлены как «soft», т.е. в виде редактируемых данных и могут быть изменены в процессе взаимодействия. Изменение элемента на любом уровне отражается на всех связанных с ним элементах немедленно. В методологии введены три уровня моделирования — метамодели, метода и проекта.
На рисунке 1 представлена предложенная многоуровневая модель, из которой видно, что между элементом power type Task/*Task и clabject #WriteMethodCode установлено отношение instanceOf. Можно сказать, что определен класс Task/*Task , специализирующий класс «паттерн power type», который на уровне проекта представлен объектом WMC1. Важно, что атрибуты объекта зеркально не отражают атрибуты clabject.
Проводя исследование процесса метамоделирования, авторы отмечают, что, следуя концепции «строгого метамоделирования», в большинстве методологий классы метамодели используются для построения классов уровня методов путем их специализации, проводимой через установление отношения реализации (instanceOf). Классы уровня метода реализуются через объекты уровня проекта. Это создает противоречие: методология представлена коллекцией классов, проект — коллекцией объектов, а способ «волшебного» превращения классов в объекты в методологиях не определен. Методология позволяет вводить контроль над преобразованием, проводимым на границе между уровнем метода и уровнем проекта.
Task
+DLiraîior
Ь-
TaskKInd
(Name +Purpose
«insla iceOf»
Notation
nName н Description
«¡nstaîceOf»
mciamoâel
Л? г! te Met hodCode
-; ■ç-
ja~asl<Kind
Name = Write MethodCode Purpose = Wriiesource code..
«insta iceOf» #WriteMethodCode
Notation
Narriez UMÇH Description = The Unified...
method
ЩС1 : WriteMethodCode
duration = 2.5 hours
project
Рис.1 - Многоуровневая модель Классы уровня метамодели рассматриваются как «сильные типы» (power type) для классов слоя метода. Каждому объекту power type класса ставится в соответствие группа объектов класса слоя метода, наследующего power type класс, при этом классы уровня метода становятся «partitioned» и определяют разделение на группы объекты в слое проекта. Таким образом, в то время как powertypes задают разделение объектов в слое метода, partitioned типы задают разбиение объектов в слое проекта. Авторы назвали такое представление двойным представлением. Строгое наследование частично подменяется прототипированием — следованием некоторому образцу, при котором наличие связи между объектами power type классов на уровне метамодели задающих классификацию, определяет необходимость установления связи такого же типа между классами уровня метода, классифицированными этими объектами. Каждому классу и его объекту уровня проекта ставится partitioned класс уровня метода и объект power type класса уровня метамодели. Такая композиция и получила название clabject. Моделирование в понятиях clabject обеспечивает возможность того, что характеристики элементов и правила их организации
как уровня метода, так и уровня проекта могут быть определены в метамодели и затем переданы на необходимые уровни, вниз — через специализацию и классификацию, вверх — через создание иерархий.
Atkinson и Kühne [2] ввели понятие «potency» и метод «deep instantiation» порождения объектов между уровнями иерархии специализации, основанный на понятии features (attributes and relationships). При этом «традиционный» метод порождения объектов из классов, присущий объектно-ориентированному подходу, рассматривается как частный случай более общего механизма, названного «deep instantiation», при котором производится специализация между clabjects, а не между классами и объектами. При специализации clabject А на основе некоторого clabject B каждой возможности (feature) элемента (атрибуту и связи) приписывается числовой атрибут «potency», значение которого определяет способ трансформации возможности элемента. Для каждой возможности элемента A со значением potency > 0 в элементе B определяется возможность со значением potency, уменьшенным на 1. При нулевом значении potency возможность атрибута элемента А представляется в элементе B как атрибут простого типа , а ассоциация элемента A представляется в элементе B ссылкой на элемент с potency=0. На всех уровнях моделирования элементы уровней характеризуются атрибутами двух типов — с potency>0 и с potency=0. Проектный уровень представлен элементами, с атрибутами, у которых potency=0. Введение potency поволило избавится от отношения powertype, определяет способ образования объектов проектного уровня из классов уровня метода с учетом спецификаций, задаваемых уровнем метамодели. Таким образом, показано существование унифицированного концепта (clabject), позволяющего проводить многоуровневое моделирование для различных предметных областей. Для обеспечения многоуровневого моделирования была предложена архитектура ортогональной классификации OCA (Orthogonal Classification Archtectute), основанной на применении принципов строгого метамоделирования и deep instantiation. Между уровнями в многоуровневой модели устанавливаются отношения классификации, когда класс более высокого уровня рассматривается как классификатор классов нижних уровней [3].
С точки зрения многоуровневого семантического моделирования существуют семантические сети, связывающие классы C и индивидуалы этих классов O посредством связей R. В качестве атомарного элемента обычно используют так называемый "RDF-триплет" (RDF - Resource Description Framework) — набор информационных сущностей "объект-предикат-субъект". Предметная область, описанная таким способом, обладает компьютерной семантикой, то есть имеется возможностью устанавливать и обрабатывать смысловые отношения между понятиями с помощью программных алгоритмов.
Семантическое или онтологическое моделирование рассматривается как способ использования гетерогенных информационных ресурсов с целью организации их в рамках единого информационного пространства информационного и как способ организации взаимодействия разнородных информационных и инструментальных систем. Решение проблемы семантической интероперабельности видится в создании универсальных, кроссплатформенных информационных структур, использующих семантические метаописания данных, аннотирующих как собственные, так и внешние разнородные информационные массивы. Процесс описания предметной области сопровождается привязкой к ней спецификаций, выраженной в концептах некоторой онтологии, согласованием понимания предметных областей взаимодействующих ресурсов и построения их взаимодействия, основываясь на согласованной семантике предметной области. Унификация информационных моделей является необходимым шагом при работе с неоднородными онтологическими спецификациями. Модели приводятся к некоему каноническому однородному представлению, в котором будут производиться все дальнейшие манипуляции спецификациями. Модели онтологий называются исходными, а каноническая модель - целевой. Задача унификации множества исходных информационных
моделей становится актуальной при необходимости масштабирования по количеству неоднородных моделей. При унификации моделей должно быть построено отображение исходных моделей в целевую. При отображении моделей производится поиск близких конструкций моделей и их выражение друг через друга [4].
Существует необходимость в декомпозиции семантической модели на атомарные элементы, более крупные, триплеты. Частично эта проблема была решена в языке OWL введением понятий онтологических классов и онтологических связей в версии языка OWL 2, позволяющей наследовать онтологические классы от индивидуалов онтологических классов. Стало возможным использование конструкций, в которых онтологический класс имеет фреймы, связанные как с другими онтологическими классами, так и с индивидуалами онтологических классов. Структурно такие конструкции подобны clabjects. Но новые возможности онтологического моделирования практически не поддерживают существующие инструменты онтологического моделирования. С другой стороны, при разработке инструментария для семантического моделирования в основном используется объектно-ориентированные методологии и технологии. При этом обычно создается некоторая семантическая модель в рамках некоторой онтологии, примитивы и результаты моделирования представлены в виде RDF-триплетов, хранимых в реляционной базе данных. В соответствии с традиционной технологией объектно-реляционного отображения каждому онтологическому классу, представленному наборов триплетов, ставится в соответствие объектно-ориентированный класс [5], что связано с трудоемкой разработкой, все еще плохо подающейся автоматизации. Для повышения эффективности необходимо, чтобы каждой семантической конструкции когнитивного уровня рассуждения был сопоставлен набор унифицированных объектов, размещенный в памяти соответствующего инструмента, автоматически создаваемого в соответствии с моделью, также представленной в виде семантической сети. В этом случае появляются возможности:
• проектирование компьютерных систем можно осуществлять на основе унифицированных логико-семантических моделей, рассматривая разработку логико-семантической модели проектируемой системы как первый этап ее проектирования
• обеспечить модульную (компонентную, крупноблочную) разработку логико-семантических моделей компьютерных систем на основе библиотек совместимых типовых многократно используемых компонентов (онтологий, логических операций и
т.д.);
• рассматривать различные варианты технической реализации компьютерных систем как различные способы интерпретации унифицированных логико-семантических моделей компьютерных систем, что дает возможность разрабатывать такие интерпретаторы независимо от проектирования конкретных систем и включать эти интерпретаторы в состав среды проектирования;
• обеспечить полную совместимость средств проектирования с проектируемыми системами - среда проектирования строится как интеллектуальная система на основе унифицированных логико-семантических моделей;
• включить в состав среды проектирования компьютерных систем комплекс интеллектуальных help-систем, ориентированных на повышение квалификации разработчиков;
• ориентироваться на методику поэтапного эволюционного проектирования компьютерных систем на основе быстрого создания прототипов [6].
Для реализации такого подхода необходимо принять решение об объектной модели унифицированного элемента, используемого для представления крупных элементов семантической сети как в оперативной, так и в долговременной памяти программного инструмента. Для построения систем проектирования, реализующих данный подход,
необходимы программные компоненты и сервисы, обеспечивающие создание, хранение и управление унифицированными семантическими сетями, представленными в виде сетей унифицированных элементов. Назовем такие атомарные элементы онтолетами. По структуре онтолеты очень похожи на онтологии — они так же, как онтологии, включают в себя онтологические классы и связи между ними. Главным отличием онтолета от онтологии является возможность на основе онтолета создавать индивидуал онтолета. Определим индивидуал онтолета как набор индивидуалов классов, входящих в состав онтолета, и связями между этими индивидуалами, структура которых тождественна структуре связей в онтолете.
Введение понятия онтолета позволяет проводить многоуровневую декомпозицию онтологической модели и рассматривать вопрос отображения онтолетов в соответствующие ОО-компоненты. Таким образом, онтологическому классу можно сопоставить онтолет схемы и онтолеты форм, на основе которых могут быть построены соответствующие ОО-компоненты.
Проектирование в терминах онтолетов может быть как восходящим, так и нисходящим. При нисходящем проектировании на каждом этапе онтолет декомпозируется в набор онтологических элементов — онтолетов, онтологических классов и связей. Окончательная онтологическая модель реализуется тогда, когда все онтолеты представлены через соответствующие связи и классы. Восходящее проектирование производится в обратном порядке, что соответствует построению метамодели и метаметамодели.
В [7] на основе объектно-ориентированной модели семантической сети [8] нами был предложен набор компонентов CADT={Ontology, OntoClass, DatProperty, ObjectProp, ClsDataProperty, ClsObjectProperty, Ontolndividual, IndDataProperty, IndObjectProperty}. Диаграмма классов набора представлена на Рисунке 2. Компоненты предназначены для представления семантической сети в объектно-ориентированной среде и хранения представления в объектно-ориентированной базе данных [9]. Было показано, что набор компонентов обеспечивает отображение высказываний языка абстрактной семантической сети в сеть объектов и позволяет создавать и сопровождать базы знаний через интерфейс пользователя веб-приложения. В настоящее время этот набор компонентов изменен.
Семантическая сеть G={{Ci}, {Rj}} рассматривалась нами как множество узлов С и связей R, причем узел имеет тип из множества типов узлов TC={Onto, OCls, OntoInd }, а связь — тип из множества связей TR={DatProp, ObjProp, ClsDatProp, ClsObjProp,IndDatProp, IndObjProp}. В настоящий момент этот набор компонентов подвергся изменению, с целью введения возможности взаимного семантического аннотирования элементов семантической сети. Эта возможность позволяет строить многоуровневую семантическую сеть, представляя ее в памяти как многоуровневую объектную модель, в соответствии с архитектурой OCA.
Определим семантику узлов и связей:
Onto — множество онтологических модулей O;
DP— множество элементов типа DatProp, определяющих сорта описания данных;
P — множество элементов типа ObjProp, определяющих сорта связей;
OCls— множество элементов типа OntoCls;
OI — множество элементов типа OntoInd;
O=<title,id ,OC, DP, OP,OI> — онтологический модуль, представляющий сеть более низкого уровня, title - наименование узла, id-идентификатор узла;
OntoCls=<title,id,subClassOf,hasKindOf,rootclass,ClsDP,ClsOP> — элемент сети, представляющий класс онтологии, subClassOf — множество классов, являющихся родительскими, hasKindOf — множество классов и объектов, аннотирующих класс семантическим описанием, rootclass— атрибут, указывающий на уровень в иерархии классов в модуле;
DatProp=<title, id, range:XMLSchemeDatetype>— тип связи, определяющий характер представления элемента сети простым типом данных, где range— множество классов, наследующих класс XMLSchemeDatetype, представляющий семейство простых типов, определяет верхний уровень в иерархии элементов типа ClsDP;
ObjProp=<title,id, range:NotXMLSchemeDatetype> — тип связи, определяющий характер связи элемента сети с элементами, не принадлежащими множеству простых типов данных, определяет верхний уровень в иерархии элементов типа ClsOP;
ClsDP=<title, id, parent, dataProperty:DProp, range> — элемент, представляющий множество значений атрибута класса parent, dataProperty указывает на элемент в частной иерархии элементов ClsDP, range— ограничение, дополнительно накладываемое на множество ограничений на тип простых значений, определяемое иерархией dataProperty ;
ClsOP=<title, id, parent, SubPropertyOf, range> — элемент, представляющий множество допустимых связей атрибута с именем title класса parent, SubPropertyOf указывает на элемент в частной иерархии элементов ClsOProp, range — ограничение, дополнительно накладываемое на множество ограничений на тип связываемых элементов, определяемое иерархией SubPropertyOf;
OntoInd=<title, id, sourceClass, IndDP, IndOP> — экземпляр класса онтологии, где sourceClass— родительский класс для экземпляра;
IndDP=<title, id, parent, dataProperty, range> — элемент, представляющий множество значений атрибута класса parent, dataProperty указывает на элемент в частной иерархии элементов ClsDP, range — ограничение, дополнительно накладываемое на множество ограничений на тип простых значений, определяемое иерархией dataProperty;
IndOP=<title, id, parent, SubPropertyOf, range> — элемент, представляющий множество допустимых связей атрибута с именем title класса parent, SubPropertyOf указывает на элемент в частной иерархии элементов ClsOProp, range — ограничение, дополнительно накладываемое на множество ограничений на тип связываемых элементов, определяемое иерархией SubPropertyOf.
На Рисунке 3 представлена связь классов различных уровней моделирования с использованием разработанного отображения и показана связь классов для компонента, отображающего элемент, представляющий clabject. Для упрощения изображения классы, представляющие связи изображены линиями. В архитектуре OCA каждому атрибуту и связи приписывалось значение числового атрибута potency. При этом максимальное значение potency имели атрибуты и связи самого верхнего уровня моделирования.
При создании модели в разработанном нами редакторе производится последовательное создание экземпляров компонентов. В предлагаемом подходе отношение онтологической классификации power type реализуется атрибутом hasKindOf класса OntoClass. Экземпляр класса OntoClass является контейнером для набора экземпляров типа ClassObjеctProperty, каждый из которых хранит информацию о связываемых элементах модели. Во многих случаях число уровней моделирования не известно и начальное значение potency не определено. Для преодоления этого недостатка мы ввели иерархию классификации между связями, определяемую атрибутом SubPropertyOf.
Рассмотрим последовательность [Cii,Ci2,...Cin] классов, наследующих друг друга и расположенных различных уровнях моделирования, т.е Cik.SubClassOf^Cik-1
Для оптимизации программы мы ввели дополнительный атрибут hasMetaClass, определяющий наследование между классами, находящимися в разных онтологических модулях, т.е. атрибуты SubClassOf и hasMetaClass семантически эквивалентны, но не могут быть использованы одновременно. Классу Cik сопоставлено множество (Щ}к связей, представленных элементами типа ClassObjectProperty и ClassDataProperty. При этом, при наследовании классов устанавливается отношение Rijk.SubPropertyOf^ Rjk-1 .Каждая связь
определяет ограничения для области определения своих значений, ограничение может быть рассчитано как Rijk(Rijk-1(■■Rij1(Rij1■range))).
Рис. 2 - Диаграмма классов набора компонентов Ограничения связи может быть указано в атрибутах связи R или определено в классе или индивидуале класса классификатора, определяемого отношением hasKindOf.
При выборе элемента модели, определяющего связь в памяти системы ищется объект типа ClassObjectProperty, и строится иерархия объектов, связанных отношением SubPropertyOf. Атрибуты объекта определяют ограничения, накладываемые на связываемые элементы. Ограничение для выбранного элемента определяется последовательной композиции ограничений всех связей более высокого уровня, при этом, если в ограничения нижнего уровня применяются к рассчитанному ограничению верхнего уровня. Правила логической состоятельности в настоящее время определены в коде редактора. Предполагается в дальнейшем правила интерпретации ограничений представить в виде соответствующей модели и редактировать их подобно другим моделям.
Рассмотрим процесс создания элемента модели GuiModel (см. Рис.3). На рисунке 4 представлен окно разработанного нами редактора концептуальных моделей в режиме редактирования класса «GUI Model», наследующего класс «GUI Model». При построении модели редактор анализирует класс «Model» и создает копии всех принадлежащих ему элементов типа ClassObjectProperty и ClassDataProperty. Атрибуты title прототипа копируются в соответствующий атрибут title создаваемого элемента. В атрибут SubPropertyOf нового элемента записывается ссылка на прототип, добавляя новый элемент в иерархию связей. Тип элементов для области значений атрибута range получается из соответствующего атрибута прототипа, затем строится список наследующих его классов. Пользователю предоставляется возможность определить ограничение на тип связываемого элемента, выбрав его из списка.
В настоящее время реализовано определение ограничений на тип связываемого объекта и определение ограничений, определяемых атрибутом hasKindOf. На рисунке показано, что класс Model классифицируется классом ModelType и все его наследники будут использоваться для разбиения наследников класса Model на группы. На рисунке 4 в качестве класса, аннотирующего создаваемый класс GUIModel, выбран класс видВизуальнаяМодель (на рисунке 3 не показан) из списка наследников класса ModelType. Атрибуты этого аннотирующего класса используются в качестве спецификации создаваемой модели.
Рис.3 - Связь классов различных уровней моделирования
Информация, созданная на уровнях моделирования, применяется для создания элементов уровня проекта. Элементы уровня проекта создаются как наборы связанных элементов типа Оп1»1пётёиа1, 1пёБ1аРгорег1у и 1пёОЬ]ес1Ргорег1у. Связи между ними определяются связями, получаемыми редактором от элементов, определенных на более высоких уровнях.
Практика показала, что создание элементов обычно не требуется. Если трактовать элементы уровня метода, как спецификации программных элементов, то элементами уровня проекта являются реальные программные элементы, физически хранимые на информационных носителях или отправляемые пользователю по сети. Эти элементы могут быть созданы специальными генераторами, описания которых берутся из уровня метода. В нашем случае, для каждого элемента любого уровня с помощью генератора пользовательского интерфейса может быть создана соответствующая форма ввода или вывода данных, отправляемая клиенту через сеть. Создание элемента проектного уровня оправдано, если эта форма должна быть подвержена дальнейшим изменениям. Но и в этом случае целесообразно, чтобы при генерации формы одновременно автоматически создавался элемент уровня метода, который может быть изменен сервисами приложения и затем использован для генерации элемента уровня проекта. Но это решение должно быть принято при разработке конкретной системы, в период выбора способа хранения данных.
Создание элементов уровня проекта в виде элементов онтологического модуля оправдано в случае, когда эти элементы рассматриваются как элементы хранения данных, подобных КОБ-триплетам, но хранимым в объектно-ориентированной базе данных.
Предложенный способ представления позволяет на разных уровнях моделирования проводить фильтрацию типов элементов, которые могут быть использованы при разработке модели выбранного типа. Созданная нами система многоуровневого семантического моделирования использует разработанные компоненты. Для выбранного типа модели в редакторе модели на основе информации о связях определяются типы примитивов моделирования и другие компоненты моделирования, например язык описания модели и тип редактора для управления моделью.
Редактировать класс Gu¡Model
Классификаторы объекта
[dEfaulij ■ ВидВи5уальнзяМэд&ль|видВизуальнаяМодель v |
Связи объекта
редактор модели • Tool NavTool у
использует язык описания • Language Gui DSL v
отображена в документе * Document документ суз v |
использует примитив моделировании • гтримитиб моделирования GUI примитив моделирования ^
имеет язык моделирования • Язык разметки TAL Not found у
включает подмодель включает примитив • Модель GuiModel у
• GUI примитив моделирования AbstractlriterfaceElement v
Рис. 4 - Редактирование GUI-модели
Ограничения на объем статьи не позволяют описать систему проектирования более подробно.
Литература
1. Brian Henderson-Sellers and Cesar Gonzalez-Perez The Rationale of Powertype-based Metamodelling to Underpin Software Development Methodologies. Получено из https://www.academia.edu/948418/The_rationale_of_powertype_based_metamodelling_to_underpin _software_development_methodologies.html
2. Atkinson, Kühne. The essence of multilevel metamodelling. In «UML»2001:Modeling Languages, Concepts and Tools, Vol. 2185. GOGOLLA , M. and KOBRYN, C. (eds). Springer-Verlag, Berlin, 19-33.
3. Colin Atkinson, Ralph Gerbig, Christian Tunjic. Towards Multi-level Aware Model Transformations. Theory and Practice of Model Transformations: 5th International Conference .с.208-223
4. Скворцов Н.А. Вопросы согласования неоднородных онтологических моделей и онтологических контекстов // Онтологическое моделирование. - 2008. - С. 149-166.
5. Beck H., H. S. (2002). Overview of approach, methodologies, standards, and tools for ontologies. Материалы Third Agricultural Ontology Workshop. Food and Agricultural Organization of the United Nations. Получено из http://aims.fao.org.
6. Голенков В.В. Принципы построения массовой семантической технологии компонентного проектирования интеллектуальных систем / В.В.Голенков, Гулякина Н.А. // Материалы междунар. науч.-техн. конф. «Открытые семантические технологии проектирования интеллектуальных систем» (OSTIS-2011). Минск, 10—12 февраля 2011 г. - Минск, 2011. - С. 21—58.
7. Грегер С.Э., Сковородин Е.Ю. Построение онтологического портала с использованием объектной базы // Объектные системы - 2010: Материалы I Международной научно-практической конференции. Россия, Ростов-на-Дону, 10-12 мая 2010 г / под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2010. С. 74-78.
8. Загорулько Ю.А. Подход к построению интеллектуальных информационных систем на основе семантических сетей // Международная научно-техническая конференция «Открытые семантические технологии проектирования интеллектуальных систем» (Open Semantic Technologies for Intelligent Systems)— OSTIS-2011, 10-12 февраля 2011 года, Минск, Белоруссия, Белорусский государственный университет информатики и радиоэлектроники.
9. Stephane JEAN, Y. A.-A. (б.д.). An Object-Oriented Based Algebra for Ontologies and their Instances, Advances in Databases and Information Systems (ADBIS'07), Varna Bulgaria,2007, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.82.68
УДК 04.004
ОСНОВНЫЕ ЭТАПЫ МЕТОДОЛОГИИ МЕТАМОДЕЛЬНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ БАЗ ДАННЫХ
Олейник Павел Петрович, к.т.н, Системный архитектор программного обеспечения, ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Ростов-на-Дону, [email protected]
Введение
Многие современные информационные системы являются программными приложениями баз данных. При этом в качестве хранилища информации используются реляционные системы управления базами данных (РСУБД), а для реализации бизнес-логики применяют объектно-ориентированные языки программирования (ООЯП). Из-за различий в подходах к управлению данными возникает так называемое объектно-ориентированное несоответствие (ОРН), для преодолений последствий которого применяется множество частных решений. В данной статье кратко описана разработанная автором методология метамодельно-ориентированного проектирования приложений баз данных (МММОППБД) которая позволяет реализовать различные этапы проектирования разрабатываемой информационной системы и в конечном итоге реализовать приложение с развитым графическим интерфейсом.
1. Этапы методологии метамодельно-оиентированного проектирования приложений баз данных
Данная методология разрабатывалась автором в течение последних нескольких лет и протестирована на множестве проектов в различных сферах деятельности: от
