CC BY
56
2. Олейник П.П. Опыт применения инструментов объектно-реляционного отображения при разработке информационной системы каталогизирования научных работ // Информационные технологии в науке, экономике и образовании: материалы 5-й Всероссийской научнопрактической конференции 2-3 сентября 2010 года / под. ред. О.Б. Кудряшовой; Алт. гос. техн. ун-т., БТИ. - Бийск: Изд-во Алт. гос. техн. уни-та, 2010. - С. 102-105.
3. Олейник П.П., Игумнов Е.А., Свечкарёв Е.А. Опыт проектирования информационной
системы для каталогизирования научных работ при проведении международных конференций // Объектные системы - 2010: материалы II Международной научно-практической
конференции. Россия, Ростов-на-Дону, 10-12 ноября 2010 г., Ростов-на-Дону, 2010. - С. 48-51.
4. Олейник П.П., Игумнов Е.А., Свечкарёв Е.А. Реализация модуля рецензирования в информационной системе проведения научных конференций // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 26-29.
УДК 04.004
УНИФИЦИРОВАННАЯ МОДЕЛЬ ТЕСТИРОВАНИЯ ИНСТРУМЕНТОВ РАЗРАБОТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРИЛОЖЕНИЙ
Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, xsl@list.ru
Введение
В настоящий момент существует множество инструментов, предоставляющих объектный подход для разработки приложений. Несмотря на наличие собственных достоинств и недостатков, основная цель их - предоставить разработчику все преимущества объектно-ориентированной парадигмы. Данная статья подробно описывает унифицированную модель тестирования инструментов разработки объектно-
ориентированных приложений, для демонстрации, которой использован графический унифицированный язык моделирования. Практическая реализация модели
продемонстрирована на примере применения классических методов (паттернов) объектнореляционного отображения (ОРО) в инструменте, разработанном автором. Таким образом, объектная модель приложения реализуется в среде реляционной СУБД. Такой подход наиболее оправдан, с точки зрения автора, потому что РСУБД - самый популярный тип систем управления БД.
1. Проектирование унифицированной модели тестирования
При проектировании унифицированной модели тестирования использован такой же подход, как при описании шаблонов (паттернов) проектирования в работе [1]. Этот подход предполагает описание многократно используемых решений широко распространённых проблем, возникающих при разработке программного обеспечения без привязки к конкретной предметной области. Основная задача данного раздела - это описание модели и структурных элементов (классов и ассоциаций), а не корректность модели и точность её соответствия конкретной предметной области.
Стандартным графическим языком моделирования различных аспектов объектных систем является язык UML. Этот язык, а именно структурные диаграммы классов, будут рассмотрены в данной работе. В итоге под унифицированной моделью тестирования инструментов разработки объектно-ориентированных приложений будем понимать диаграмму классов, состоящую из классов и атрибутов, и содержащую наиболее часто встречающиеся на практике отношения классов.
23
Идея статьи не нова, и имеются работы сходной тематики. Так, в работе [2] уже была предпринята попытка построения унифицированной модели тестирования. Однако там отсутствовали множественные (n-арные) ассоциации и ассоциации с атрибутами, которые являются неотъемлемым элементом любой сложной информационной системы.
В работе [3] представлена тестовая модель для обучения проектированию объектноориентированных баз данных. Но эта модель относительно проста, что оправдано её назначением. В данной статье использованы достоинства имеющихся ранее работ, и исправлены недостатки, присущие им.
Перед проектированием унифицированной модели тестирования были выдвинуты критерии оптимальности (КО), представляющие требования о наличии определенных структурных элементов на диаграмме классов и которым должна соответствовать готовая реализация. Были выдвинуты следующие требования для унифицированной модели тестирования инструментов разработки объектно-ориентированных приложений:
1. Необходимо наличие глубоких иерархий наследования. В реальных приложениях очень часто появляются глубокие иерархии, представляемые отношением наследования и объединяющие транзитивно не менее трех классов.
2. Присутствие нескольких иерархий наследования. Это позволит продемонстрировать различные опции и режимы, имеющиеся в инструменте.
3. Наличие абстрактных классов в иерархии. Абстрактные классы не могут иметь экземпляров в системе и описаны в качестве контейнеров для атрибутов и методов, используемых в производных реальных (инстанцируемых) классах.
4. Присутствие множественных n-арных ассоциаций. В приложениях, автоматизирующих реальные прикладные области, часто возникают ассоциации, в которых участвуют три и более класса. Подобные отношения называют множественными или n-арными ассоциациями.
5. Наличие ассоциаций с атрибутами. Многие предметные области содержат атрибуты, которые не принадлежат определенным сущностям, и их значения появляются только при организации связей между экземплярами классов. Проектируемая унифицированная модель должна иметь ассоциации с атрибутами.
6. Присутствие композиции между классами. Композиция - это ассоциация между классами, представляющими Часть и Целое. Особенность в том, что класс, представляющий Часть, может входить только в один экземпляр класса, представляющий Целое. При этом класс, представляющий Целое, управляет жизненным циклом класса, представляющего Часть. Т.е. при удалении Целого, Части также удаляются. Эта особенность поведения очень важна для многих прикладных предметных областей.
7. Наличие рекурсивных ассоциаций. Рекурсивными называют ассоциации, концы которых связывают один и тот же класс. Подобные отношения позволяют реализовать иерархию подчинения.
8. Наличие ассоциаций между классами, входящими в одну иерархию наследования. С точки зрения реализации необходимо предусмотреть реализацию ассоциации, края которых связывают классы, входящие в одну иерархию наследования, т.е. представляют базовый и дочерний класс друг к другу.
9. Присутствие класса-ассоциации. Класс-ассоциация - это ассоциация, которая в то же время является и классом. Особенность использования в том, что класс-ассоциация представляет собой уникальную ассоциацию, т.е. комбинация экземпляров классов в этой ассоциации является уникальной.
10. Наличие ассоциаций между классом-ассоциацией и другим классом. С теоретической точки зрения класс-ассоциация - это класс, поэтому он может участвовать в других ассоциациях. С точки зрения реализации класс-ассоциация
24
приставляет собой класс, содержащий атрибуты (поля или свойства языка программирования), которые ссылаются на другие классы. В свою очередь, для организации ассоциации с классом-ассоциацией необходимо в зависимом классе создать атрибут, типом которого выступает класс-ассоциация.
11. Присутствие в модели перечислений. С теоретической точки зрения перечисление -это набор предопределенных констант, при этом пользователю нельзя расширить этот набор путем добавления новых значений.
В соответствии с выделенными критериями была реализована иерархия, представленная на рис. 1.
Рассмотрим назначение основных классов представленной диаграммы. Как говорилось ранее, данная диаграмма классов является вымышленной и не предназначена для описания конкретной предметной области, поэтому содержит некоторые нелогичные (вымышленные) классы и ассоциации.
Для представления сотрудников и организаций выделен базовый абстрактный класс Contragent. Унаследованный класс Company представляет организацию, а класс Worker является базовым для сотрудника организации. Унаследованный класс Employee представляет служащего и содержит атрибут EID, представляющий табельный номер. Класс Manager представляет сотрудников, которые являются руководителями для других работников.
Абстрактный класс Post представляет собой должность, которую может занимать сотрудник. Унаследованный класс ExperiencePost представляет собой должность, которая требует от претендента минимального количество опыта, выражаемого количеством месяцев (атрибут MinExperMonth). Второй реализованный класс ScientificRank описывает должность от соискателя, на которую требуется наличие ученой степени, название которой записано в атрибуте AcademicRank.
Рис. 1 - Унифицированная модель тестирования инструментов разработки объектноориентированных приложений
Для представления отделов организации и вхождения в n-арную ассоциацию, введен класс Department. Класс Salary представляет выплаченную заработную плату, начисленную работнику, занимающему должность, представленную сложной ассоциацией Position.
Класс Telephone позволяет представить номер телефона контрагента. Тип телефона (Домашний, Личный, Рабочий) представлен перечислением TelephoneKind. Для представления адреса используется базовый абстрактный класс Address. Два производных класса CompanyAddress и EmployeeAddress используются для представления адреса организации и адреса служащего соответственно.
Теперь проверим соответствие представленной модели выделенным ранее критериям оптимальности. Необходимость наличия глубокой иерархии классов, представленная как
25
минимум тремя транзитивно унаследованными классами, описана KOi и реализована классами Contragent, Worker, Employee, Manager. Кроме этой, имеются еще две иерархии: 1) Post, ExperiencePost (ScientificPost); 2) Address, CompanyAddress (EmployeeAddress). Т.е. в модели присутствуют несколько иерархий наследования, следовательно, выполнено условие KO2. Наличие абстрактных классов в иерархии обусловлено КО3 и выполнено классами Post, Contragent и Address.
Требования КО4 также выполнены, т.к. имеется n-арная ассоциация Position, объединяющая классы Post, Department, Worker, Company. Т.к. описываемая ассоциация содержит атрибут Rate, реализованный классом-ассоциацией и бинарная ассоциация, соединяющая классы Employee и EmployeeAddress также содержит атрибут (IsRegistered), то можно утверждать, что требование КО5 выполнено.
У каждого контрагента, представленного производными от Contragent классами, имеется список номеров телефоном, представленных экземплярами класса Telephone, и оба класса связаны композицией, т.е. требование КО6 выполнено. Унифицированная модель позволяет сохранять информацию о группе компаний, т.е. организовать древовидную структуру с помощью рекурсивной ассоциации соединяющей класс Company с собой же. Наличие рекурсивной ассоциации продиктовано КО7.
В КО8 записано требование наличия ассоциаций между классами, входящими в одну иерархию наследования. На рисунке 1 между классами Employee и Manager имеется подобная ассоциация, удовлетворяющая КО8. Как отмечалось ранее, в модели имеется наличие класса-ассоциации Position, что соответствует КО9. Описанный класс-ассоциация соединен дополнительной ассоциацией с классом Salary. Это следствие выполнения КОш. Присутствие в модели перечислений обусловлено выполнением КО11. Из представленного описания видно, что унифицированная модель полностью соответствует всем выделенным ранее критериям оптимальности. Поэтому можно переходить к реализации унифицированной модели.
2. Классические методы (паттерны) объектно-реляционного отображения
Для реализации представленной модели использовалась среда разработки программных комплексов на основе организации метамодели объектной системы, представленная в работах [4-5]. Эта среда разработки получила название SharpArchitect RAD Studio и в качестве хранилища информации использует реляционную СУБД. Т.к. информационная система проектируется в понятиях объектно-ориентированной парадигмы, а реализуется в среде реляционной СУБД, то возникает так называемое «объектно-реляционное несоответствие», для преодоления последствий которого используются методы (паттерны, шаблоны) объектно-реляционного отображения. Наиболее часто используются паттерны для представления иерархии классов.
В SharpArchitect RAD Studio реализуются три классических метода реализации объектно-ориентированного отношения наследования классов в виде реляционной структуры (реляционных отношений), представленные на рисунке 2 [2, 4].
Рассмотрим основные представленные методы более подробно. Метод Наследование с одной таблицей (Single Table Inheritance) физически представляет иерархию наследования классов в виде одной таблицы реляционной базы данных, столбцы которой соответствуют атрибутам всех классов, входящих в иерархию и позволяющих отобразить структуру наследования и минимизировать количество соединений, которые необходимо выполнить для извлечения информации. В данном методе каждому экземпляру класса соответствует одна строка таблицы. При создании объекта значения заносятся только в те столбцы таблицы, которые соответствуют атрибутам класса, а все остальные остаются пустыми (имеют null-значения).
26
Метод Наследование с таблицами для каждого конкретного класса
Рис. 2 - Классические методы (паттерны, шаблоны) объектно-реляционного отображения, используемые для представления наследования классов в виде реляционной структуры (реляционных
отношений)
Метод имеет достоинства:
• В структуре БД присутствует лишь одна таблица, представляющая все классы иерархии.
• Для извлечения экземпляров классов иерархии нет необходимости выполнять соединение таблиц.
• Перемещение полей из базового класса в производный (так же из производного в базовый) не требует внесения изменений в структуру таблицы.
Методу присущи недостатки:
• При изучении структуры таблиц БД могут возникнуть проблемы, ведь не все имеющиеся столбцы таблицы предназначены для описания каждого класса предметной области. Это усложняет процесс доработки системы в будущем.
• При наличии глубокой иерархии наследования с большим количеством атрибутов многие столбцы могут иметь пустые значения (null-маркеры). Это приводит к неэффективному использованию свободного пространства в БД. Однако современные СУБД способны сжимать строки, содержащие большое количество отсутствующих значений.
• Итоговая таблица может оказаться слишком большой и содержать огромное число столбцов. Основной способ оптимизировать запрос (сократить время выполнения) -создать покрывающий индекс. Однако множество индексов и большое количество запросов к одной таблице способны привести к частым блокировкам, что будет оказывать негативное влияние на производительность программного приложения.
27
Альтернативным является метод Наследование с таблицами для каждого класса (Class Table Inheritance), представляющий иерархию классов по одной таблице для любого класса (как абстрактного, так и реализованного). Атрибуты класса отображаются непосредственно на столбцы соответствующей таблицы. При использовании данного метода ключевой является задача соединения соответствующих строк нескольких таблиц БД, представляющих единый объект предметной области.
Метод имеет следующие преимущества:
• В каждой таблице присутствуют лишь поля, соответствующие атрибутам определённого класса. Поэтому таблицы легки для понимания и занимают мало места на жёстком диске.
• Взаимосвязь между объектной моделью и схемой базы данных проста и понятна. Однако имеются недостатки:
• При создании экземпляра определённого класса необходимо выполнить загрузку данных из несколько таблиц, что требует либо их естественного соединения, либо множества обращений к базе данных с последующим соединением результатов в оперативной памяти.
• Перемещение полей в производный класс или суперкласс требует изменения структуры нескольких таблиц.
• Таблицы суперклассов могут стать слабым местом в вопросах производительности, поскольку доступ к таким таблицам будет осуществляться слишком часто, что приведёт к множеству блокировок.
• Высокая степень нормализации может стать препятствием к выполнению незапланированных заранее запросов.
Метод Наследование с таблицами для каждого конкретного класса (Concrete Table Inheritance) представляет иерархию наследования классов, используя по одной таблице для каждого реализованного (неабстрактного) класса этой иерархии. С практической точки зрения данный метод предполагает, что каждый экземпляр класса (объект), который находится в оперативной памяти, будет отображён на отдельную строку таблицы. При этом каждая таблица в нашем случае содержит столбцы, соответствующие атрибутам как конкретного класса, так и всех его предков.
Преимуществами являются то, что:
• Каждая таблица не содержит лишних полей, вследствие чего ее удобно использовать в других приложениях, в которых не использован инструмент объектнореляционного отображения.
• При создании объектов определённого класса в памяти приложения и извлечения данных из реляционной базы данных выборка выполнятся из одной таблицы, т.е. не требуется выполнять реляционные соединения.
• Доступ к таблице осуществляется только в случае доступа к конкретному классу, что позволяет снизить количество блокировок, накладываемых на таблицу и распределить нагрузку на систему.
При этом имеются недостатки:
• Первичные ключи могут быть неудобны в обработке.
• Отсутствует возможность моделировать отношения (связи) между абстрактными классами.
• Если атрибуты классов перемещаются между суперклассами и производными классами, требуется изменять структуру нескольких таблиц. Эти изменения будут не так часты, как в случае наследования с таблицами для каждого класса, однако их нельзя игнорировать (в отличие от метода Наследование с одной таблицей, в котором эти изменения вообще отсутствуют).
28
• Если в суперклассе изменить определение хотя бы одного атрибута (например, поменять тип данных), это потребует изменить структуру каждой таблицы, представляющей производный класс, поскольку поля суперкласса дублируются во всех таблицах его производных классов.
• При реализации метода поиска данных в абстрактном классе потребуется просматривать все таблицы, представляющие экземпляры производных классов. Это требует большого количества обращений к базе данных.
Выбор соответствующего метода ОРО зависит от исходной логической модели, т.е. от иерархии классов предметной области. При этом одновременно могут использоваться два и более метода ОРО, что связано с необходимостью оптимизировать структуру реляционной БД и сократить количество используемых таблиц, что позволит увеличить скорость выполнения запросов на выборку данных.
Описав используемые в SharpArchitect RAD Studio паттерны объектно-реляционного отображения, которые доступны разработчику, можно приступить к реализации унифицированной модели тестирования.
3. Реализация унифицированной модели тестирования
С целью упрощения процесса реализации разобьем три имеющихся на рисунке 1 иерархии классов в соответствии с имеющимися методами ОРО. Результат представлен на рисунке 3.
Рис. 3 - Применение классических методов ОРО для реализации унифицированной модели тестирования инструментов разработки объектно-ориентированных приложений
Метод Наследование с одной таблицей будет использован для иерархии классов Post, ExperiencePost (ScientificPost). В результате предполагается, что в РБД будет создана одна единственная таблица (отношение БД), в которой будут сохранены экземпляры всех перечисленных неабстрактных классов. Для иерархии классов Contragent, Worker (Company), Employee, Manager используется метод Наследование с таблицами для каждого класса. Т.е. для всех классов независимо от того абстрактный он или реализованный будет создана отдельная таблица РБД. Класс Address является абстрактным и не имеет ассоциаций с другими классами модели, поэтому для него не будет создаваться отдельная таблица в РБД. А для дочерних классов будет создано две таблицы (по одной для каждого наследника). Т.е. для иерархии Address, CompanyAddress (EmployeeAddress) применен метод Наследование с таблицами для каждого конкретного класса. Для остальных классов, не входящих в описанные иерархии, будет создано по отдельному отношению.
29
Одной из основных особенностей SharpArchitect RAD Studio является поддержка множественного наследования, реализуемого с помощью интерфейсов (interface) языка C#, что подробно описано в [4]. Применяемый язык C# не поддерживает такой синтаксической конструкции, как ассоциация. Для представления бинарных ассоциаций независимо от множественности используются свойства (property), содержащие одно значение или коллекцию значений.
Множественные n-арные ассоциации представляются отдельным классом, атрибуты этих ассоциаций (как и атрибуты бинарных ассоциаций) превращаются в свойства классов. Для упрощения поиска информации и извлечения все ассоциации являются двунаправленными, т.е. на обоих краях в соответствующих классах присутствуют свойства, тип которых соответствует классу противоположного конца ассоциации. Все описанные выше рассуждения графически представлены на рис. 4.
Post Л Department A Contragent A ft Telephones Telephone ft
Interface f ♦ IBaseRunTimeDomainClass 1 Positions ♦ IBaseRunTimeDomainClass ♦ IBaseRunTimeDomainClass ft Contragent ' ' ♦ IBaseRunTimeDomainClass
© Properties ft Name © Properties ft Name © Properties ft Name ■ ; В Properties ft Number
В Properties
ft MinErperMonth
Address
♦ iBaseRunTimeDomainClass
Э Properties ft Building ft Otу ft Country ft Office ft Street
Position
»| Interface
♦ IBaseRunTimeDomainClass
В Properties ft Rate
Worker
♦ Contragent
В Properties « ft DateQfdirth
~iy~
Company ft
Interface ♦ Contr agent
+ IBaseRunTimeTreeNodeDomainClass
TelephoneKind ft
Enum
Home
Personal
Work
ScientificPost ft V
Interface
-fPost
Э Properties
ft AcaderNcRank ft Salaries
V J
\ '
_T T_
ft CompanyAddress
Employee
Interface ■+ Worker
ft Employees
H Properties
ft EmpbyeeEmployeeAddresses
-»Ti
CompanyAddress ft
♦ Address
© Properties ft Date ft Value
ft Manager Г
Manager ft
♦ Employee
jnTimeDomainClas1
► EmpfoyeeEmpfoyeeAdtifesses -------------------
В Properties
ft IsRegistered
ft EmpfoyeeAddress
EmployeeAddress ft
ч ,
Рис. 4 - Унифицированная модель тестирования инструментов разработки объектноориентированных приложений, реализованная в SharpArchitect RAD Studio на языке C#
При реализации использовались интерфейсы языка C#, поэтому невозможно курсивом выделить абстрактные классы. Двунаправленные ассоциации показаны соответствующими стрелками, соединяющими классы. При реализации ассоциаций использовался следующий подход. Со стороны «один» создавалось свойство (property), типом которого является список (C# тип IList<>), содержащий элементы, типом которых является класс, расположенный со стороны «ко-многим». При этом со стороны «ко-многим» в классе объявляется свойство, тип которого является класс, расположенный со стороны «один». Ассоциация типа «многие-ко-многим» (без атрибутов) может быть представлена двумя списками, объявленными в противоположных классах. В среде разработки SharpArchitect RAD Studio имеется ряд базовых классов, в которых реализован наиболее общий функционал. Например, класс IBaseRunTimeDomainClass является корневым для всех классов предметной области. Для реализации древовидной структуры достаточно унаследоваться от IBaseRunTimeTreeNodeDomainClass. В момент кодогенерации автоматически будут генерироваться дополнительные атрибуты Nodes и Owner, позволяющие сохранять ссылки на вложенные и родительский узлы соответственно. Именно таким способом реализуются рекурсивные ассоциации. Для представления перечислений и множеств используется синтаксическая конструкция enum.
Теперь, применяя классические методы ОРО, было получено реляционное представление унифицированной модели. На рис. 5 изображён результат.
30
Рис. 5 - Реляционное представление реализации унифицированной модели тестирования в
SharpArchitect RAD Studio
Рисунок требует пояснения. Для всех должностей, представленных тремя классами Post, ExperiencePost и ScientificPost, создана одна единственная таблица Post, в которой присутствуют все атрибуты классов. Дополнительно в таблице присутствует столбец OID, представляющий объектный идентификатор (первичный ключ в реляционной модели). Столбец ObjectType содержит идентификатор класса, объекты которого сохранены в виде строк таблицы. Это значение используется приложением для создания класса объектноориентированного языка программирования и для загрузки значений атрибутов.
При реализации метода Наследование с таблицами для каждого класса были созданы таблица Contragent для абстрактного класса и таблицы Worker, Company, Employee, Manager для реализованных классов. Таким образом, экземпляры классов физически хранятся в нескольких таблицах базы данных. А экземпляр класса Manager хранится во всех таблицах.
При реализации метода Наследование с таблицами для каждого конкретного класса, применимого для классов Address, CompanyAddress и EmployeeAddress, было создано две таблицы: CompanyAddress и EmployeeAddress, т.к. класс CompanyAddress является
абстрактным. Все атрибуты абстрактного класса физически сохраняются в таблицах конкретных классов.
Для n-арной ассоциации Position создана отдельная таблица так же, как и для бинарной ассоциации, соединяющей классы Employee и EmployeeAddress, для которой создана таблица EmployeeEmployeeAddress, содержащая внешние ключи.
Отметим, что для перечисления TelephoneKind отдельная таблица не создавалась. Использовался подход представления значений перечисления в виде битовой маски и сохранения полученного значения в виде целого числа там, где используются соответствующие атрибуты. Так, в таблице Telephone имеется столбец TelephoneKind, SQL-тип которого Integer.
Проанализировав перечисленное выше, можно утверждать, что представленная на рисунке 5 реализация, созданная в среде разработки SharpArchitect RAD Studio, полностью соответствует унифицированной модели тестирования инструментов разработки объектноориентированных приложений, представленной на рисунке 1.
Выводы
Дальнейшим развитием унифицированной модели является проверка реализуемости в различных средах разработки приложений. При этом планируется альтернативная
31
реализация и с помощью подходов, представленных другими авторами, занимающимися сходными научными проблемами.
Литература
1. Гамма Э. и др. Приёмы объектно-ориентированного проектирования. Паттерны проектирования, СПб: Питер, 2001. - 368 с.: ил. (Серия «Библиотека программиста»)
2. Олейник П.П. Унифицированная модель для тестирования инструментов объектнореляционного отображения // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 65-69.
3. Олейник П.П. Тестовая модель для обучения проектированию объектно-ориентированных баз данных // Объектные системы - 2014: материалы VIII Международной научнопрактической конференции (Ростов-на-Дону, 10-12 мая 2014 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, 2014. - С. 86-89.
4. Олейник П.П. Элементы среды разработки программных комплексов на основе организации метамодели объектной системы // Бизнес-информатика. 2013. №4(26). - С. 69-76.
5. Олейник П.П., программа для ЭВМ "Унифицированная среда быстрой разработки корпоративных информационных систем SharpArchitect RAD Studio", свидетельство о государственной регистрации № 2013618212 от 04 сентября 2013 г.
УДК 004.434:004.82
ИСПОЛЬЗОВАНИЕ ОБЪЕКТНЫХ МОДЕЛЕЙ В РЕШЕНИИ ЗАДАЧ ИНЖЕНЕРИИ
ЗНАНИЙ СИСТЕМ ПЛАНИРОВАНИЯ1
Малышко Виктор Васильевич, кандидат физико-математических наук, доцент, Московский
Государственный Университет имени М.В.Ломоносова, Россия, Москва, vmalyshko@cs.msu.ru Манжосов Андрей Николаевич, аспирант, Московский Государственный Университет имени М.В.Ломоносова, Россия, Москва, amanzhosov@gmail.com
Работа выполнена в рамках исследования новых методов работы с базами знаний систем планирования (грант РФФИ № 14-01-00214). В ней рассматриваются вопросы представления знаний и программной поддержки их целостности. Актуальной задачей для нас является выбор средств представления знаний систем планирования. При выборе уделяется внимание автоматизированному выявлению ошибок в базе знаний системы планирования, проверке корректности найденных системой планов, имитации их выполнения, а также генерации входных описаний для планировщиков на традиционных языках искусственного интеллекта.
Подход, которого мы придерживаемся при решении указанных вопросов, основывается на адаптации современных языков и программных средств инженерии программного обеспечения к использованию в области искусственного интеллекта. Языки UML [1] и OCL [2] позволяют создавать сложные подробные и точные формальные модели для любых предметных областей. В этом можно увидеть предпосылки к тому, чтобы применять UML в инженерии знаний. Чтобы это стало возможным, нужно предложить представление знаний в виде UML-моделей и создать средства их перевода в описания знаний на языки, традиционно используемые в искусственном интеллекте.
Одной из работ по практическому использованию UML в инженерии знаний систем планирования является проект itSIMPLE (the Integrated Tools Software Interface for Modeling PLanning Environments) [3], осуществляемый в университете Сан-Паулу. В среде itSIMPLE
1 Работа выполнена в рамках исследования новых методов работы с базами знаний систем планирования (грант РФФИ № 14-01-00214)
32
