CC BY
48
реализация и с помощью подходов, представленных другими авторами, занимающимися сходными научными проблемами.
Литература
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
Малышко Виктор Васильевич, кандидат физико-математических наук, доцент, Московский
Государственный Университет имени М.В.Ломоносова, Россия, Москва, [email protected] Манжосов Андрей Николаевич, аспирант, Московский Государственный Университет имени М.В.Ломоносова, Россия, Москва, [email protected]
Работа выполнена в рамках исследования новых методов работы с базами знаний систем планирования (грант РФФИ № 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
знания систем планирования описываются на языке UML/P, представляющем собой подмножество UML, изменённое и приспособленное для представления знаний планировщиков. Среда itSIMPLE предоставляет средства моделирования знаний, их анализа и имитации выполнения планов решения задач.
В отличие от бразильских коллег, мы полагаем, что моделировать предметные области и задачи следует не в специализированной среде инженерии знаний, а в универсальной среде программной инженерии - Eclipse Modeling Tools [4].
Рис. 1 - Схема применения среды Eclipse Modeling Tools для решения задач инженерии знаний
Согласно предлагаемой нами схеме инженеры знаний будут создавать в среде Eclipse Modeling Tools UML-модели, описывающие предметные области и задачи планирования. По созданным UML-моделям автоматически будут сгенерированы описания на широко используемом входном языке планировщиков - PDDL [5]. Получив PDDL-описания знаний, программы-планировщики будут осуществлять поиск планов. Корректность найденных планов будет исследована при помощи сгенерированных по ним объектным спецификациям, которые будут поданы на вход средства спецификации и валидации. В качестве такого средства мы предлагаем использовать среду USE (UML-based Specification Environment) [6]. Она позволяет имитировать выполнение планов и осуществить их оценку. Результатами работы USE будут наборы «снимков» состояний задач и вердикты о корректности планов.
Предлагаемая нами схема позволит решать задачи, стоящие перед инженером знаний, при условии, что будет предложен способ представления знаний на языке UML, будет реализован генератор PDDL-описаний по UML-моделям и будет реализован генератор USE-спецификаций. Все эти условия нами выполнены. Далее в статье предлагается способ представления знаний и обсуждается построение генераторов.
Способ представления знаний в виде UML-моделей мы рассмотрим на примере задачи о перевозке пассажиров. В этой предметной области выделяются три типа объектов: остановки, автобусы и пассажиры. Остановки соединены дорогами, по которым могут следовать автобусы. Автобусы перемещаются между остановками, перевозя одновременно не более некоторого фиксированного количества пассажиров. Пассажир может зайти в автобус, если тот находится на той же остановке, что и пассажир, и в автобусе достаточно свободных мест. Также пассажир может покинуть автобус на какой-либо остановке.
Знания о рассматриваемой предметной области описываются в виде модели, диаграмма классов которой приведена на рисунке 2а. В ней присутствуют три класса: Bus (автобус), Station (остановка), Passenger (пассажир). Каждый класс описывает один из типов объектов предметной области. Отношения между объектами задачи представлены ассоциациями: at (пассажир находится на некоторой остановке), atStation (автобус находится на некоторой
33
остановке), inside (пассажир находится в автобусе), stationToStation (остановка напрямую соединена дорогой с другой остановкой). Атрибутом seatNumber класса Bus обозначено свойство объектов-автобусов - общее количество мест в автобусе, то есть максимально возможное количество одновременно перевозимых им пассажиров. Действия пассажиров по входу и выходу из автобусов описаны в классе Passenger операциями getIn(b:Bus) и getOut(). Операция moveTo(st:Station) в классе Bus описывает переезд автобуса от текущей остановки к напрямую соединённой с ней дорогой остановке st.
Формальное и точное описание действий задаётся пред- и постусловиями операций, выраженными на языке OCL, а также телами операций, записанными на языке SOIL (Simple OCL-based Imperative Programming Language) [6], который представляет собой лаконичное императивное расширение языка OCL:
context Bus::moveTo(st:Station) pre connectedStations:
elf.station.from^union(self.station.to)^includes(st) post busArrived: self.station = st body moveToSOIL: begin
delete(self, self.station) from atStation; insert(self, st) into atStation; end
context Passenger::getIn(b:Bus)
pre passengerAtBus: self.station = b.station
pre busIsNotFull: b.seatNumber - b.passenger^size() > 0
post passengerInsideBus: b.passenger = b.passenger@pre^including(self) post passengerlsNotAtStation:
self.station.passenger = self.station.passenger@pre^excluding(self) body getInSOIL: begin
delete(self, self.station) from at; insert(self, b) into inside; end
context Passenger::getOut()
pre passengerInsideBus: self.bus^notEmpty()
post passengerAtStation:
self.station.passenger = self.station.passenger@pre^including(self)
post passengerIsNotInsideBus:
self.bus.passenger = self.bus.passenger@pre^excluding(self)
body getOut: begin
insert(self, self.bus.station) into at; delete(self, self.bus) from inside; end
context Bus
inv BusIsNotOverloaded: self.seatNumber - self.passenger^size() >= 0
Начальные условия конкретной задачи описываются диаграммой объектов, на которой представлены экземпляры классов, их свойства и связи. Рассмотрим экземпляр задачи, в котором присутствуют остановки Serpukhov, Chekhov, Klimovsk, Podolsk, пассажиры: Fedor, Andrey и Ivan, двое из которых находятся в Podolsk, а оставшийся - в Chekhov. Автобус paz находится в Serpukhov, и в нём всего два места. Диаграмма представлена на рисунке 2б.
Цель задачи описывается OCL-выражением, которое истинно тогда и только тогда, когда пассажиры окажутся на назначенных им местах. Например, следующее выражение задаёт цель перевести всех пассажиров в Serpukhov:
context 4Stations3Passengers def:
goal:Boolean = (Fedor.station = Serpukhov) and (Ivan.station = Serpukhov) and (Andrey.station = Serpukhov)
34
Можно видеть, что знания о предметных областях и задачах планирования могут быть описаны в виде моделей UML. Эти модели достаточно наглядны и понятны. В тоже время, модели подробны и формальны, так что они могут быть проверены в Eclipse Modeling Tools для выявления расхождений между условиями задачи и описанием предметной области или других ошибок.
«domain»
BusDomain
stationT oStation
«task»
4Stations3Passengers
а) Диаграмма классов с описанием предметной области
б) Диаграмма объектов с начальными условиями задачи
Рис. 2 - диаграммы UML-модели предметной области и начального состояния задачи
Например, можно убедиться, что в начальном состоянии не выполнено условие достижения цели задачи, не выполнено предусловие операции getOut() объекта Andrey класса Passenger, но выполнено предусловие операции getln(paz) этого объекта и т. д.
Выше было отмечено, что для использования знаний, представленных в виде UML-модели, программой-планировщиком, нужно перевести описания на язык PDDL. Это преобразование можно осуществить автоматически с помощью разработанного генератора PDDL-текстов по UML-моделям. Основой генератора является отображение, задающее соответствия между конструкциями UML, OCL и SOIL, которыми представлены знания и цепочками PDDL.
Программная реализация генератора осуществлена с помощью инструмента Acceleo, входящего в состав Eclipse Modeling Tools. Она представляет собой набор из 19 шаблонов. Чтобы дать представление о шаблонах Acceleo рассмотрим два из них, генерирующие определения типов объектов предметной области. Первый шаблон generateTypes создаёт открывающую и закрывающую скобки и циклически обращается к вспомогательному шаблону generateType для получения списка типов. В коде шаблонов жирным начертанием выделены строки, из которых строится итоговый текст. Кроме этих строк, в результат включаются имена классов из UML-модели предметной области, обозначенные элементом шаблона [c.name.toLower()/].
[template private generateTypes(aPackage : Package) ]
(:types
[for ( elem : Class | (getClasses(aPackage)) )]
[generateType(elem)/]
[/for]
)
[/template]
[template private generateType( c : Class ) ]
[c.name.toLower()/] -
[if ( c.superClass^size() > 0 )]
[for ( sc : Class | c.superClass ) separator(’ ’)]
[sc.name.toLower()/]
[/for]
35
[else]
object
[/if]
[/template]
В результате работы этих двух шаблонов с UML-моделью задачи о перевозке пассажиров будет получено следующие PDDL-описание:
(:types
passenger - object bus - object station - object)
Другие шаблоны обеспечивают перевод ассоциаций в предикаты, целочисленных атрибутов классов - во флюенты, операций - в действия. Часть шаблонов генератора переводят экземпляры классов и соединения между ними, описывающие начальные условия задачи, и OCL-выражение, задающее цель, в PDDL-текст. Например, для рассмотренной выше задачи будет сгенерировано следующее описание:
(define (problem 4Stations3Passengers)
(:domain BusDomain)
(:objects Serpukhov - station Chekhov - station Klimovsk - station Podolsk - station Fedor - passenger Andrey - passenger Ivan -passenger paz - bus)
(:init (stationToStation Chekhov Klimovsk) (stationToStation
Serpukhov Chekhov)
(stationToStation Klimovsk Podolsk)
(at Andrey Podolsk) (at Fedor Podolsk) (at Harry Chekhov)
(atStation paz Serpukhov) ( = (seatNumber paz) 2))
(:goal (and (at Andrey Serpukhov) (at Fedor Serpukhov) (at Ivan
Serpukhov))))
Описание задачи вместе с PDDL-описанием предметной области может быть подано на вход программе-планировщику, которая найдёт план (см. первый столбец таблицы 1). Для проверки корректности плана следует убедиться, что, стартуя из начального состояния задачи, можно выполнить действия, предписанные планом, не нарушая их ограничений. Также надо проверить, что в последнем состоянии выполняется условие достижения цели.
Рассмотрим, как проверяется план с помощью инструмента программной инженерии -специализированной среды USE, осуществляющей верификацию и симуляцию выполнения объектных спецификаций.
Чтобы использовать USE в нашей задаче, нужно средство, переводящее UML-описания и план в спецификации среды USE. Для этого служит генератор спецификаций, реализованный нами на базе Acceleo. Результатом работы генератора является спецификация, содержащая описания классов, ассоциаций, операций с предусловиями, постусловиями и телами, набор команд для создания начального состояния задачи, набор команд, соответствующий плану, а также OCL-запрос, поверяющий, достигнута ли цель.
Приведём фрагменты сгенерированной спецификации. Первый фрагмент описывает класс Bus, его атрибут и операции, и ассоциацию atStation, задающую отношение между автобусом и остановкой, на которой тот находится, и инвариант класса.
class Bus attributes
seatNumber : Integer operations
moveTo(st : Station) begin
delete(self, self.station) from atStation; insert(self, st) into atStation;
36
end
pre connectedStations:
self.station.from^union(self.station.to)^includes(st) post busArrived: self.station = st
end
association atStation between Bus[*] role bus Station[1] role station end
constraints
context Bus inv BusIsNotOverloaded:
self.seatNumber - self.passenger^size() >= 0
Второй фрагмент является последовательностью команд среды USE, создающей начальное состояние задачи (текст приводится в двух колонках).
Icreate Andrey : Passenger Icreate Fedor : Passenger Icreate Ivan : Passenger Icreate Serpukhov : Station Icreate Chekhov: Station Icreate Klimovsk: Station Icreate Podolsk: Station Icreate paz : Bus Iset paz.seatNumber:= 2
Iinsert(Andrey, Podolsk) into at Iinsert(Fedor, Podolsk) into at Iinsert(Ivan, Chekhov) into at Iinsert(paz, Serpukhov) into atStation Iinsert(Serpukhov, Chekhov) into stationToStation
Iinsert(Chekhov, Klimovsk) into stationToStation
Iinsert(Klimovsk, Podolsk) into stationToStation
Третий фрагмент является OCL-запросом, соответствующим цели задачи:
?Andrey.station = @Serpukhov and Fedor.station = @Serpukhov and Ivan.station = @Serpukhov
Таблица 1. План решения задачи и соответствующая ему последовательность команд USE
План решения задачи Последовательность команд среды USE
((moveTo paz Chekhov) Ipaz.moveTo(Chekhov)
(moveTo paz Klimovsk) Ipaz.moveTo(Klimovsk)
(moveTo paz Podolsk) Ipaz.moveTo(Podolsk)
(getIn Andrey paz) IAndrey.getIn(paz)
(getIn Fedor paz) IFedor.getIn(paz)
(moveTo paz Klimovsk) Ipaz.moveTo(Klimovsk)
(moveTo paz Chekhov) Ipaz.moveTo(Chekhov)
(moveTo paz Serpukhov) Ipaz.moveTo(Serpukhov)
(getOut Fedor) IFedor.getOut()
(getOut Andrey) IAndrey.getOut()
(moveTo paz Chekhov) Ipaz.moveTo(Chekhov)
(getIn Ivan paz) IIvan.getIn(paz)
(moveTo paz Serpukhov) Ipaz.moveTo(Serpukhov)
(getOut Ivan)) IIvan.getOut()
Сгенерированная по плану последовательность команд представлена во втором столбце таблицы 1. Среда имитирует выполнение команд последовательности, предоставляя возможность наблюдать на диаграмме объектов меняющееся состояние задачи. В ходе выполнения контролируется соблюдение инвариантов, предусловий и постусловий действий. Можно проверить выполнение условий достижения цели в любом состоянии задачи.
Финальное состояние задачи, построенное средой, показано на рисунке 3. В этом состоянии цель достигнута, что подтверждается вычислением OCL-запроса, приведённого выше. В ходе имитации все ограничения, соблюдались. Проверено, что план корректен.
Рассмотренная предметная область достаточно проста, как и задача. Они выбраны лишь для того, чтобы послужить иллюстрацией. Задачи и предметные области, на работу
37
с которыми рассчитан способ представления знаний и создаваемые программные инструменты, гораздо сложнее. Пример такого рода приведён в работе [3].
Инженеру знаний невозможно обойтись без программных инструменты, автоматизирующих его работу, в ситуациях, когда в предметной области количество типов объектов и связей более десяти, когда много действий и велико количество флюент, когда в задаче участвует значительное количество объектов (20 и более), когда планы решений содержат несколько десятков шагов.
Рис. 3 - Диаграмма объектов, визуализирующая финальное состояние задачи
Подведём итоги. Предложен способ представления описаний предметных областей и задач планирования в виде объектных моделей, составленных на языках UML, OCL и SOIL. Определена схема применения среды Eclipse Modeling Tools для решения задач инженерии знаний. Созданы генератор PDDL-описаний и генератор спецификаций среды USE для проверки корректности найденных планов. На примере рассмотрены описание знаний в виде UML-моделей, генерация входных описаний для планировщиков, генерация спецификации по UML-модели и плану, получение вердикта о корректности плана.
Литература
1. Арлоу Д., Нейштадт И. UML 2 и унифицированный процесс. Практический объектно-
ориентированный анализ и проектирование, 2-е издание. СПб.: Символ-Плюс, 2007. 624 с.
2. Warmer J., Kleppe A. The Object Constraint Language: Getting Your Models Ready for MDA,
Second Edition. Boston: Addison-Wesley, 2003. p. 240.
3. Vaquero, T.S. et al. Planning and Scheduling Ship Operations on Petroleum Ports and Platforms. In:
Proceedings of the ICAPS 2012 Workshop on Scheduling and Planning Applications (SPARK),
8-16 p. Atibaia, Sao Paulo, Brazil. 2012.
4. Steinberg D., Budinsky F., et al. EMF: Eclipse Modeling Framework, Second Edition. Boston:
Addison-Wesley, 2008. 744 p.
5. Goldman R. P., Keller P. “Type Problem in Domain Description!” or, Outsiders’ Suggestions for
PDDL Improvement. ICAPS 2012 Proceedings of the 3rd WS-IPC. - 2012. - pp. 43-48.
6. Buttner, F., Gogolla, M., Modular Embedding of the Object Constraint Language into a Programming
Language. In: Simao, A., Morgan, C. (Eds.), Proc. 14th Brazilian Symposium on Formal Methods
(SBMF'2011). Springer, Berlin, 2011. LNCS 7021, pp. 124-139.
7. Musset J. et al. Acceleo documentation. - 2012.,
http://help.eclipse.org/luna/topic/org.eclipse.acceleo.doc/pages/index.html?cp=5
38
УДК 004.02
УПРАВЛЕНИЕ РЕКЛАМОЙ В КОРПОРАТИВНОЙ ГАЗЕТЕ С ПОМОЩЬЮ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
Шафоростова Елена Николаевна, к.п.н., доцент, Старооскольский технологический институт НИТУ «МИСиС», Россия, г. Старый Оскол, [email protected]
Ковтун Нелли Игоревна, старший преподаватель, Старооскольский технологический институт НИТУ «МИСиС», Россия, г. Старый Оскол, kovtun-n-i@,vandex,ru Лазарева Татьяна Ивановна, старший преподаватель, Старооскольский технологический институт НИТУ «МИСиС», Россия, г. Старый Оскол, [email protected]
Михайлюк Екатерина Андреевна, старший преподаватель, Старооскольский технологический институт НИТУ «МИСиС», Россия, г. Старый Оскол, [email protected]
Объектом разработки информационной системы является процесс управления рекламной деятельностью в корпоративном издании ОАО «Лебединский ГОК». Актуальность разработки информационной системы вызвана изменениями в законодательстве и требованиями к специфике построения редакционно-издательских систем. Анализ информационных потоков позволил выявить зависимости
функционирования, внешние и внутренние факторы, влияющие на производственный цикл, и разработать модель рабочего потока и обеспечения его данными.
Информационное обеспечение разрабатываемой ИС представляет собой совокупность данных, средств их описания, методов организации, хранения, накопления и доступа к информационным массивам, обеспечивающих выдачу всей информации о выпуске, клиенте и т.д., необходимой в процессе приема и размещения рекламного заказа.
Информационная база (база данных) составляет информационный базис системы, в ней регистрируются текущие сведения, поступающие извне, накапливаются учетные и архивные сведения, необходимые для анализа и планирования. К оперативной информации относятся данные о клиенте, данные о заказе.
Имея четкую структуру заказов на рекламу, легко определить самые выгодные предложения, узкие места и скрытые резервы. На каждый вид работ может быть определена своя норма прибыли, рассчитана рентабельность, это поможет оперативно реагировать на изменения рынка и принимать решения относительно инвестиций и ценовой политики. Подобная система выполняет функции оперативной регистрации и последующей обработки заказов, а также сбор статистической информации [1]. В общем случае необходимо организовать:
• каталог клиентов;
• регистрацию заказов;
• реестр заказов;
• статистическую обработку и анализ данных;
• документооборот.
Рекламную деятельность издания можно разделить на два этапа: работа с клиентами и размещение рекламы в номере, каждый из них отличается специфическим набором операций [2].
Во время общения с клиентом выявляется вся необходимая для обработки входная информация. Так как обработка рекламы идет сразу по нескольким направлениям: финансовые расчеты, размещение и изготовление, оформление и публикация, информация, собираемая при работе с рекламодателем, очень разнородна. По сути, первый этап обеспечивает набор данных для всех последующих. Отсутствие каких-либо данных, например, о размере или дате размещения объявления, сделает невозможной его публикацию (рис.1).
39
