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

УДК 681.3

КОНЦЕПТУАЛЬНАЯ СЕМАНТИЧЕСКАЯ МОДЕЛЬ ТЕСТИРОВАНИЯ ИНСТРУМЕНТОВ РАЗРАБОТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРИЛОЖЕНИЙ

В ПОНЯТИЯХ ОНТОЛОГИЙ

Грегер Сергей Эдуардович, Уральский федеральный университет имени первого Президента России

Б.Н.Ельцина, Нижнетагильский технологический институт (фил.). Факультет экономики и менеджмента, кафедра информационных технологий, доцент. Россия. Нижний Тагил,

segreger@gmail.com

Процесс разработки ИС описывается как последовательность стадий, включающая стадию функциональной декомпозиции требований к ИС и стадии сопоставления каждой функции некоторого аппаратного или программного элемента. В процессе функциональной декомпозиции на определенном уровне возникает ситуация, когда множеству (Fj функций сопоставляется множество «атомарные» элементов (Sj, каждый из которых не подлежит изменению из-за технологических, юридических или иных ограничений. Каждый такой элемент является отдельной системой с собственной функциональной и структурной моделью, и их следует рассматривать как поставщиков некоторых «возможностей». В настоящее время такой вид системы в теории систем определяется термином «система систем». Определяющим для повышения эффективности разработки ИС становится не создание программного кода, а повторное использование компонент, фиксация опыта их использования, построение модели из согласования. Решение проблем видится в создании формализованных описаний в виде семантических моделей и дальнейшем управлении ими с использованием технологий управления знаниями и методов декларативного программирования. Ранее нами был предложена интеллектуальная система проектирования программного обеспечения, реализующая описываемый подход [1]. В качестве обеспечивающей системы нами используется система управления знаниями, реализованная как веб-приложение на основе CMS Plone, координирующая и согласующая деятельность нескольких независимых систем с целью создания программного средства. В настоящее время такое согласование возможно в рамках обеспечивающей системы S06=<Sapp, SDomain, Sfask, Si„fo, SComp, SgwSnciv, >, предоставляемые следующими системами:

SApp — разрабатываемая целевая система, в рамках которой производится согласование;

SDomain — система, управляющая знаниями о предметной области;

SInfo — система управления информационной моделью;

Scomp — система управления программными компонентами;

Som — система управления представлением информации;

SNav — система управления коммуникациями.

Согласование группы систем возможно в рамках системного подхода, при выделении в качестве системообразующих нескольких факторов, таких как — архитектура системы, требования заинтересованных лиц и подхода стандарта ISO 42010 (Рекомендованная практика архитектурного описания программоемких систем). В этом стандарте архитектура системы рассматривается как согласование архитектурных описаний, учитывающих интересы (concerns) заинтересованных сторон (stakeholders). Архитектурное описание представлено моделями, описывающими связь функции системы и ее конструкции. Каждая группа описаний (ГО), включающая набор моделей, раскрывает отдельный аспект системы, а набор групп образует ее полное описание. Соглашения, по которым ГО создается, отображается и анализируется, устанавливаются методом описания (viewpoint).

138

Представим архитектуру ИС как Arch={ADesci}, где ADesci =<Mi, Ai, Ri, Zi >, i=1,.. ,,n, где i - аспект, характеризующий некоторую группу интересов через архитектурное описание ADesci, отвечающее способу описания Zi. Архитектурное описание связывает множество элементов M, определенных на множестве их атрибутов Ai , через отношения Ri. Будем рассматривать согласование несколько групп описаний:

• концептуальной ГО, предоставляющей описание предметной области системы;

• функциональной ГО, представляющей описания заинтересованных лиц, их задач, функции, реализующие эти задачи;

• группа описаний деятельности, рассматривающая жизненный цикл системы;

• структурная группа описаний, представляющая систему как конструкцию, состоящую из различных компонент.

Сопоставим каждой группе описаний некоторую онтологию ОГО, определяющую ее предметную область и представленную как композиция базовых онтологий — онтологию ОПдО множества объектов (понятий, концептов) ПдО, которая рассматривается как иерархическая структура классов, подклассов и элементов классов; онтологию процессов ОП в предметной области и онтологию задач О, которые могут быть поставлены и решены в ПдО. Тогда Ого = (0rtlC,On03), В качестве формальной модели информационной системы используем определение онтологической системы, предложенное Т.А.Гавриловой [2]:

уи <Qmeta {qq&I} yini >

d&b

-inf-

где:

Ometa — онтология верхнего уровня (метаонтология), элементами которой являются всевозможные предметные области, с отношениями: включение, объединение,

пересечение, декомпозиция, гомоморфизм, изоморфизм, теоретико-множественная онтология, логическое описание, логическая онтология;

{Od&t} — множество предметных онтологий и онтологий задач предметной области;

inI О

у — модель машины вывода, ассоциированной с онтологической системой у .

Тогда:

OM=<Meta, ODomain, ONav, OInfo, OComp, OGui, OApp, RaF> где:

0Об— онтология обеспечивающей системы.

Meta — метаонтология, определяющая общий словарь;

OApp — онтология приложения, являющаяся результатом разработки;

ODomain — онтология предметной области;

OTask — онтология задач;

ONav — онтология коммуникаций;

OInfo — онтология информационных элементов;

OComp — онтология компонентов;

OGui — онтология пользовательского интерфейса;

RО — множество бинарных отношений между концептами и индивидуалами онтологий;

F — машина вывода, позволяющая интерпретировать сеть онтологий.

В каждой из ранее выделенных баз знаний Oi возможно выделить две структурные части, представленные онтологией знаний и онтологией данных: Oi={OPi,ODi}, где OP — онтология представления знаний, представляющая понятия предметной и проблемной области ИС и семантические связи между ними; OD — онтология представления данных, включающая в себя экземпляры понятий из ОР. В [3] нами был предложен набор

139

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

ориентированных приложений, представленная в нотации UML. Рассмотрим процесс создания концептуальной модели в виде объектно-ориентированной семантической сети. На рисунках 1-4 представлены классы созданной нами онтологии и связи между ними в виде таксономии, созданной в разработанном нами редакторе концептуальных моделей [5].

Рассмотрим некоторые особенности представленной концептуальной модели. При ее разработке мы пытались максимально отделить сущности, представляющие элементы предметной области, от их поведенческих описаний. Так нам представляется нецелесообразным связывать классы Contingent, Worker, Employee унифицированной модели отношением наследования и вводить класс Manager только для указания должностной подчиненности. С нашей точки зрения система отношений должность — делегирована сотруднику — сотрудник, сотрудник — делегировано работнику — физическое лицо более точно описывает систему отношений в предметной области и позволяет сделать максимально независимыми архитектурные описания, введенные в модель. В модели неявно определены несколько архитектурных описаний — личный состав организации, организационная структура отделов, иерархия должностей. Неявное определение моделей выражено тем, что эти модели не представлены соответствующими классами, что целесообразно делать при разработке онтологии задач, после выделения классов заинтересованных лиц и их ролей в информационной системе.

Аналогичным образом, структурная организация отделов и должностная иерархия слабо связана с описанием личного состава организации. Такое построение отношений при дальнейшей разработке позволит максимально независимо определять интерфейсы управления моделями. Для определения ограничений, налагаемых на связи, введен специальный тип связи «ограничение на связь». Этот тип связи, наряду с типами «классподкласс», «часть-целое» и некоторые другие, определены в онтологии информационных элементов, которая является внешней для рассматриваемой онтологии и здесь нами не рассматривается. Отметим только, что при создании связи между классами онтологии мы можем указать тип отношения через специальный графический интерфейс системы разработки. Тип «ограничение на связь» используется в классе «требование к должности», в отношении «имеет стаж работы». Для указания минимального значения стажа введено отношение «value >5», указывающее на отношение «имеет стаж работы».

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

В данной статье мы коснулись только некоторых особенностей использования семантического моделирования при разработке программных систем.

140

.L Contragent

■ L fb2 Сотрудник

i- _2. имеет профиль

i- ^ профиль сотрудника ■L ииееет EID

[^Табельный номер ■ L _2. включает профиль

■L [iJ контакты сотрудника о имеет телефон b- н> адрес

Ъ- '.J-общий физнческото лица <| включает профиль ^ .Я. дата рождения <1 фамилия _d. иия d отчество

Ь- _о_ д-елетироБанс работнику

■L ‘«3 Организация

■L j± включает отдел

i- ‘uJ отдел организации ■L _fj. включает организацию i- 'uJ Организация Ь Jj_ имеет профиль

i- >yj профиль организации

i- _о. включает профиль

f- ',J общий юридического лица i- ^ контакты организации

- физическое лицо i- имеет профиль

Рис. 1- Раздел онтологии 1

телефон

I * * ^ Massif :тип телефона | Дои&дкуй

j f ЛкчныЙ

| * Рабочей

4- '*3 тип телефона ! ^ Домашнгй

j Л)^нв1Й

j *■ Рабочей

4 wjAajwc

j j ■ и ciassit: егд адреса

! У _4_ страна

! I- город

| 4- iLy^^a

I 4- _ii здак»>&

I * _4_ nweu*en№

f uJ вед адреса

Рис. 3 - Раздел онтологии 3

■•- LJ Табельный номер У _tj_ EID

У '.J EtringType . I- требование с должности ■L _о. value>5

! - д! имеет стаж работы .L о ученая степень=кандидагт

/- _ц имеет ученую степень .L о имеет ученую степень У Мученая степень У _t^ имеет стаи работы

■ <■ U ученая степень

£ кандидат У доктор

■ С? отдел организации

У Ji. включаеет отдел

У отдел организации

■ *■ ^должность

■L д! подчинен

У '.J должность

,l _о. делегирована сотруднику У Сотрудник ■L д! имеет в подчинении У '.J ДОЛЖНОСТЬ

У _о_ состБетстБует требованиям У '.J требование к должности

Рис. 2 - Раздел онтологии 2

У Sn профиль

У й общий физического лица ! Л включает профиль У .«.дата рождения

У ill фамилия У ^ИНЯ

a jrf отчество

У йобщий юридического лица 1 л включает профиль

* А. полное наименование У @3 профиль сотрудника

У jSLHneeer ЕЮ

У л включает профиль

У Й контакты сотрудника а- Й общин физического лица

* .«.делегировано работнику

У ьз Физическое лицо У & профиль физического лица j У _н. включает профиль У $3 профиль организации

ч Л. включает профиль

У Q общий юридического лица а- fi контакты оржаняззции У йконтакты

У Й контакты сотрудника i л имеет телефон у Дадрес

У й контагты организации У Л. имеет телефон Ч _о имеет адрес У й контакты физического лица У л имеет телефон У JL имеет адрес у Л включает профиль

Рис. 4 - Раздел онтологии 4

141

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

Литература

1. Грегер С.Э. Интеллектуальная система проектирования веб-приложений. Объектные системы - 2013: материалы VII Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2013 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ),

2013. с.50-54

2. Гаврилова Т.А. Базы знаний интеллектуальных систем. СПб: Питер, 2000. 384 с.

3. Грегер С.Э., Сковородин Е.Ю. Построение онтологического портала с использованием объектной базы - Объектные системы - 2010: Материалы I Международной научнопрактической конференции. Россия, Ростов-на-Дону, 10-12 мая 2010 г / под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2010. С. 74-78.

4. Олейник П.П. Унифицированная модель тестирования инструментов разработки объектноориентированных приложений - Объектные системы - 2014 (Зимняя сессия): материалы IX Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова,

2014. -С. 23-32.

5. Ахметов Д.Р., Грегер С.Э. Редактор онтологий для онтологоуправляемой информационной системы. Объектные системы - 2013: материалы VII Международной научно- практической конференции (Ростов-на-Дону, 10-12 мая 2013 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2013.с.80-82.

УДК 681.3

ИНТЕГРАЦИЯ СЕМАНТИЧЕСКИХ МОДЕЛЕЙ ДОКУМЕНТА

Грегер Сергей Эдуардович, Уральский федеральный университет имени первого Президента России

Б.Н.Ельцина, Нижнетагильский технологический институт (фил.). Факультет экономики и менеджмента, кафедра информационных технологий, доцент. Россия. Нижний Тагил,

segreger@gmail.com

Жуйкова Ольга Сергеевна, студент, Нижнетагильский технологический институт филиал уральского федерального университета имени первого Президента России Б.Н. Ельцина, Россия,

Нижний Тагил, Zhuikova-nt94@vandex.ru

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

«Сервис интеграции» основан на разработанных модулях (загрузки, изменения, удаления, форматирования информации и т.д.) CMS Plone. Совокупность всех созданных модулей позволяет организовать модель ИС, которая позволяет решать многие задачи:

1. Хранение материалов.

2. Поиск необходимого материала (выполнение запросов).

3. Редактирование материалов.

4. Формирование документов и их форматирование.

5. Сохранение документа в необходимом формате.

142