CC BY
59
УДК 007:159.995
ПРЕДСТАВЛЕНИЕ ЗНАНИЙ В ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ БАЗЕ ДАННЫХ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ УПРАВЛЕНИЯ ФИРМОЙ1
Долятовский Валерий Анастасиевич, д.э.н., проф., заведующий кафедрой менеджмента, Ростовский государственный экономический университет, Россия, Ростов-на-Дону, dvaleri@inbox.ru Сергеенко Григорий Сергеевич, к.э.н., доцент, с.н.с., "Meridian Cons.", Чехия, Прага, grigor@mail.ru Долятовский Леонид Валерьевич, к.э.н., доцент кафедры менеджмента, Ростовский государственный экономический университет Россия, Ростов-на-Дону, ldleon@mail.ru
Гамалей Н.Ю. , аспирант, Ростовский государственный экономический университет, Россия, Ростов-
на-Дону, ngamaley@mail.ru
Ведение
Объектно-ориентированная база данных (ООБД) является важным блоком системы управления предприятием, и ее формирование должно соответствовать принципам объектноориентированного проектирования. Основным принципом построения ООБД является формализованное семантическое описание ситуаций и его отображение на действия (решения), сформулированные в форме менеджерских глаголов. Тем самым строится менеджерская грамматика адаптивного управления фирмой. Первой составляющей ООБД является словарь объектов (менеджерских существительных) и их атрибутов. Организация этого словаря представлена на рис. 1. По существу, он представляет собой классификационную таблицу, структура которой соответствует фреймовому представлению знаний и использует основное преимущество такого представления: фрейм, как структура описывает одну из единиц обработки, обладающую до некоторой степени независимостью, и может предоставлять средства, связывающие между собой эти структурные элементы.
Номер предметной области
Порядковый номер объекта в /-ой предметной области
Код Имя^объекта Атрибуты объекта
Код Имя атрибута
Прибыль Доход
Ай? Общиеиздержки
Принадлежность атрибута объектуП.
пЧ
г .
Lk+1
Порядковый номер атрибута
Рис. 1 Организация словаря менеджерских существительных
Если сравнивать фреймовую систему с традиционной программной системой, то можно сказать о снятии ограничений последовательного процесса обработки за счет того, что обрабатываемые единицы описываются в виде фреймов, которые не обязательно следуют один за другим. Этап конструирования словаря объектов и атрибутов отражает два первых этапа объектно-ориентированного проектирования. Второй составляющей ООБД является словарь менеджерских глаголов. Конструкция этого словаря включает код предметной области, наименование глагола и его содержательную структуру.
Структура словаря глаголов по наличию различных иерархических связей гораздо проще, чем словарь объектов и атрибутов. Однако по семантическому содержанию словарь
1 Статья рекомендована к опубликованию в журнале "Информационные технологии и вычислительные системы"
89
глаголов представляет собой довольно насыщенную структуру, занимающую достаточно большой объем дискового пространства. Конструирование словаря менеджерских глаголов только частично отражает третий этап объектно-ориентированного проектирования. Перейдем к рассмотрению третьей составляющей ООБД - семантической сети.
Семантическая сеть осуществляет в полной мере третий этап объектноориентированного проектирования и производит простое, быстрое, эффективное и наглядное представление взаимодействия объектов, атрибутов и глаголов между собой. Семантическая сеть позволяет описать практически все менеджерские знания, необходимые для дальнейшего анализа деятельности фирмы. Таким образом, можно сделать вывод, что ООБД представляет собой определенным образом организованную и поддерживаемую языковыми и программными средствами совокупность взаимосвязанных между собой объектов, хранимых на технических носителях, и описывающих, в нашем случае, предметную область менеджмента. В основе организации ООБД лежит модель данных. С помощью модели данных представляются множества объектов и описываются взаимосвязи между ними. Результатом системного подхода к проблеме является концептуальная модель. Как следует из названия, концептуальная модель отражает концепции исследования и определяется его целями и возможностями. Концептуальную схему ООБД можно представить в следующем виде (рис. 2).
Рис. 2 Концептуальная схема объектно-ориентированной базы данных
В связи с тем, что одной из основных характеристик, которым должна удовлетворять разработанная интеллектуальная активная система управления предприятием (ИНТЕЛАС), является оперативность представления и обработки информации и знаний, то единственно возможным вариантом обеспечения этого требования является конструирование распределенной ООБД (РООБД). Под распределенной будем понимать такую ООБД, структура которой расчленена и разнесена по различным узлам локальной вычислительной информационной сети анализируемого предприятия (ЛВС). Распределенные объектноориентированные базы данных и построенные на их основе системы децентрализованной обработки знаний представляют собой новое, эффективное средство автоматизации процесса
90
принятия решения. Именно такая технология разработки ООБД использована при проектировании ИНТЕЛАС.
При формировании ООБД необходимо учитывать границы объекта и степень декомпозиции. Следует подчеркнуть, что такое выделение возможно именно в рамках изучаемой проблемы; для иной формулировки проблемы разделение на рассматриваемую систему и окружающую среду будет иным. Например, если рассмотреть в качестве изучаемой системы некоторое предприятие в целом (завод); то границы системы определяются территорией завода (возможно и другими объектами, такими как филиалы, фирменные магазины и т.п.), а в окружающую среду войдут поставщики, конкуренты, клиенты, местная администрация и др. И формирование ООБД будет опираться именно на эти границы предприятия в целом. Однако легко представить себе цель исследования, требующую рассмотрения не завода в целом, а некоторой его подсистемы (например, сборочного производства). Тогда сборочное производство становится изучаемой системой, а остальные производства и службы завода - внешней средой. В этом случае ООБД будет представлять собой более низкий уровень декомпозиции глобальной ООБД.
1. Разработка управленческих триггеров в базе знаний первого типа (БЗ 1)
В результате проведенных исследований выявлено, что работа ИНТЕЛАС начинается при появлении отклонения «движения» предприятия от желаемой траектории, то есть при
S Ф0. При этом конструкция этого множества представляет собой набор логических фильтров или триггеров (содержание БЗ 1) для выявления ситуаций управления (содержание
БЗ 2). Однако множество S содержит лишь идентификаторы сложившихся событий, которые уже после выявления поступают в БЗ 2, где по номеру уже открываются структурированные знания. Для выделения сложившейся ситуации вполне возможно применять несколько методов. Наиболее простым способом является анализ условий возникновения ситуаций и отслеживание значения атрибутов некоторого объекта с последующим построением дерева продукционных правил (в нашей интерпретации -классификационное дерево). Вначале формируется таблица состояний, где каждому состоянию ставятся в соответствие некоторые соотношения между конкретными значениями атрибутов или самих объектов. Пример такой таблицы приведен в табл. 1.
Таблица 1. Условия и ситуации системы
Ситуации Условия отношений атрибутов
А^ > Cj A2q■ < C2 А3Ц' = C 3 А 4^i < C 4 A5Qi > C5 АбЦ' < C6
E1 True False False False False False
E2 False True False True False False
Ез False False True True False False
Е4 False False False False True False
Е5 False False False False False False
Примечание. Q, i = 1,6 - ограничивающие константы (или ограничения в
продукционных правилах); Et, i = 1,5 - ситуации, возникновение которых влечет за собой выработку управленческих воздействий.
После выделения такой таблицы строится продукционное дерево правил выявления сложившейся ситуации. Разработанные основы построения продукционных правил использованы для наполнения БЗ 1. По существу, они представляют собой знания первого типа. Для реализации представления этих знаний были использованы синтаксические основы языка VBA, семантическое содержание которых однозначно соответствует некоторым логическим глаголам ИНТЕЛАС. Приведем их структуру для обеспечения соответствия между концептуальной и физической фазой проектирования БЗ 1.
Синтаксис 1.
91
IF условие THEN утверждения [ELSE другие утверждения ]
Синтаксис 2.
IF условие THEN [утверждения]
[ELSEIF условие^ THEN [другие утверждения^]] . . .
[ELSE
[другие утверждения]]
END IF
На основании предложенных концепций была построена база знаний первого типа для предприятия. При построении управленческих триггеров использовались комплексы известных эмпирических закономерностей, такие как теория массового обслуживания, теория управления запасами, теория фирмы (прикладная экономика для менеджеров [1]), основы финансового менеджмента [2] и т.д. В таблице 2 приведен пример списка пятнадцати проблемных ситуаций.
аблица 2. Список проблемных ситуаций
Идентификатор Проблемная ситуация
E001 Уменьшение прибыли
E002 Уменьшение объема реализации
E003 Повышение общих расходов
E004 Нехватка производственных площадей
E005 Моральный износ оборудования
E006 Физический износ оборудования
E007 Несоответствие фонда заработной платы объемам производства
E008 Финансовый дисбаланс
E009 Потеря доли рынка
База знаний БЗ 1 содержит в себе управленческие триггеры, необходимые для выявления сложившейся негативной ситуации. Следовательно, самым эффективным методом, позволяющим представить знания такого типа, является продукционная система. Особенность продукционных правил заключается в легкой системе построения выводов, основанной на дереве И/ИЛИ. Кроме этого, выраженная модульность правил позволяет задавать новые значения, не вдаваясь в смысл других знаний. Именно продукционная система, направленная на простые, однородные по свойствам задачи, эффективно описывает знания БЗ 1, но практически не применима в других функциональных блоках из-за своей ограниченности.
2. Структуризация знаний о проблемных ситуациях в базе знаний второго типа
В соответствии с назначением базы знаний второго типа (хранение структурированных знаний проблемных областей), мы сталкиваемся с проблемой представления знаний. Методы представления знаний были описаны выше и проанализирован способ их оптимального использования в ИНТЕЛАС. Однако решение этой задачи не снимает проблему нечеткости при представлении именно менеджерских знаний. Таким образом, перед формированием базы знаний второго типа необходимо решить проблему представления знаний.
Знания могут представляться на различных уровнях, в зависимости от их содержательной «наполненности», причем каждому уровню будет соответствовать отдельная форма представления. На рис. 3 приведена схема работы БЗ 2. Анализ приведенной иллюстрации показывает, что при формировании БЗ 2 в зависимости от принадлежности знания к тому или иному уровню необходимо использовать различные формы их представления. При проектировании БЗ 2 все знания, связанные с разработкой ИНТЕЛАС, были реализованы в виде модулей, физически представляющих собой файлы MS Word и рабочие листы MS Excel, с включениями в них текста управляющей программы
92
VBA. Причем текст программы несет на себе не только управленческие функции, но и является одной из форм представления знаний в виде функциональных и других зависимостей.
Функционирование БЗ 2 при надобности активизирует или блок стохастических моделей, или блок детерминированных постановок. Так, например, если на вход БЗ 2 поступила информация о стохастическом законе распределения спроса на товар фирмы, то она передает необходимый код ситуации и далее происходит переход в ситуацию подключения стохастической двухэтапной модели с инерционно-стратегическими связями между переменными, результатом решения которой становится нахождение оптимального решения поставленной задачи.
Результатом работы БЗ 2 является вывод рекомендаций менеджеру в менеджерское окно с параллельным представлением некоторых знаний, требующихся для иллюстрации выбранных альтернатив. Далее, в соответствии со структурной схемой функционирования ИНТЕЛАС менеджер осуществляет предложенное действие и параллельно подключается база знаний третьего типа.
Менеджерское окно
Рис. 3 Логика функционирования базы знаний второго типа
Разработанная логика проектирования интеллектуальной системы управления предприятием была применена при построении системы управления нефтехимическим предприятием и позволила существенно ускорить процессы анализа управленческих ситуаций.
Литература
1. Долятовский В.А. Экономика для менеджеров. - Ростов-на-Дону: РГЭУ "РИНХ", 2009. - 167 с.
2. Doliatovski V.A., Sergeenko G.S. The concept of firms diagnostic // Intelligent systems “INTELS’98”/Proceeding of the Third International Symposium. (30.06-4.07.1998) - Moscow, Russia, 1998. -pp. 122-124.
93
УДК 004.4
СОВРЕМЕННОЕ СИСТЕМНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ КОМПОНЕНТНОГО ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ1
Ермаков Илья Евгеньевич, преподаватель, Технологический институт Орловского государственного технического университета, технический директор, НПО «Тесла», Россия, Орёл,
ermakov@metasystems.ru
Введение
Создание современных программных систем надлежащего качества невозможно без использования соответствующих системных средств, как инструментального характера, применяемых на этапе разработки, так и платформенного характера, обеспечивающих этап выполнения. Платформы выполнения предоставляют поддержку базовых абстракций, с использованием которых реализована программная система, и всех механизмов, необходимых для её работы. В статье представлен обзор современной проблематики системного ПО и применяемых в этой сфере инженерных подходов.
1. Универсальные языки высокого уровня
Появление новых задач в ИТ традиционно стимулировало внедрение новых языков программирования (концепции которых обычно были разработаны задолго до своего широкого распространения).
Для десятилетия 90-х характерен рост интереса к языкам повышенного уровня — технологиям 4GL, генерационным CASE-системам, функциональному и декларативному программированию. Как обычно бывает, завышенные начальные ожидания сменились этапом реальных применений, когда эти инструменты распространились в тех нишах, где они уместны, и потерпели фиаско там, где их пытались привить безосновательно.
Можно уверенно говорить, что существует оптимальный языковый уровень для широкого класса задач. На этом уровне находится категория универсальных эффективно компилируемых императивных языков программирования. Из промышленных языков это преимущественно два семейства: Паскаль-семейство (Oberon/-2/-07, Component Pascal, Ada/95/2005, Modula-2/3 и т.д.) и C-семейство — (C, C++, D и т.д.), на верхней границе этой категории — синтетическое семейство Java-C#, частично производное от Оберона.
Наиболее исследованные, ставшие рутинными задачи постепенно охватываются высокоуровневыми инструментами, т.е. переходят из сферы программирования в сферу параметризации специализированных генерационных инструментов, каркасов и т.п. Однако неизменным остаётся то, что новые, наиболее актуальные и интересные задачи требуют полноценного программирования - в том же режиме, как и «бывшие интересные» задачи, а любое полноценное программирование при росте размеров и сроков жизни системы требует полноценного, универсального, качественно спроектированного ЯВУ (а не сделанных «на скорую руку» сценарных и макроязыков). Точно так же при масштабировании системы быстро приобретает остроту проблема эффективности, что требует применения компилируемых языков из названного выше класса. Разбор аргументов в пользу класса универсальных компилируемых языков и требований, исходящих от задач системного программирования, выполнен, в частности, Б. Страуструпом в книге «Дизайн и эволюция языка С++» [1].
Направление с популярным названием «Cloud Computing», которое инициировано такими лидерами отрасли, как Google и Microsoft, вывело на первый план категорию задач сложного серверного ПО. Оказывается, что распространённые языковые инструменты недостаточно хороши для этой сферы: С++ небезопасен и крайне сложен (как в реализации, так и в применении), Java и C# не так эффективны для системного программирования, как
1 Статья рекомендована к опубликованию в журнале "Информационные технологии и вычислительные системы"
94
