CC BY
28
мультиагентных систем. На примере понятия алгоритма становятся очевидны не содержательные, а формальные сложности, возникающие в новой предметной области в связи с наследованием ею понятийного аппарата предшествующего этапа информационной эволюции программирования. Подобный подход позволяет показать, что дискурсивные (понятийные) сложности, являясь формальными по характеру происхождения, значительно задействуют семантический и прагматический уровни программного кода (помимо синтаксиса). По сути, программист вынужден решать семиотические задачи о коллизии новых и уже бытующих знаковых систем. Наибольшим флуктуациям и сомнениям понятие алгоритма подвергается в программных отраслях, связанных с искусственным интеллектом, ассоциативными и семантическими сетями, нечеткими множествами: именно здесь проблема формализации задачи, ее разрешимости и хотя бы теоретической вычислимости встает на первый план. Всякое ли содержание может быть сведено к набору знаний, представленному совокупностью формул и пропозициональных форм? Алгоритмизация решения сводится, в кибернетическом плане, к проблеме останова машины Тьюринга для соответствующей задачи или, в математическом плане, к теореме Геделя о неполноте всякой формальной системы. Адаптация термина непроста и в случае мультиагентных систем, где требуется иное понимание последовательности шагов.
Данный пример демонстрирует, насколько важна теоретическая чуткость при описаниях новой техно-
логической платформы. Сегодня становятся невозможными грамотная концептуализация производственного замысла и постановка технического задания с использованием унифицированного жаргона индустриальной эры.
Информационная эпоха порождает новые представления, новые представления формируют новые понятия, новые понятия корродируют имеющийся символический порядок. Рождающаяся информационная парадигма сталкивает уютный мир уже обжитых значений с новой, тревожащей символической платформой, где информация определяет всякую возможную содержательность человеческого измерения жизни, а сетевая фактура наилучшим образом материализует дух информации. Сегодняшней социальности уже недостаточно быть воплощенной в информации - важно научиться транслировать себя в будущее, защищать себя от развоплощения нестойким носителем, запечатлевать себя в дисперсной, распределенной среде сетевых систем, буквально ин-формировать себя.
Литература
1. Кастельс М. Информационная эпоха: экономика, общество и культура. - М.: ГУ ВШЭ. - 608 с.
2. Коротков А. Послесловие к матрице: виртуальные миры и искусственная жизнь. - М.: Деловая культура, Альпина Бизнес Букс, 2005. - 312 с.
3. Семенов С.В., Лещев В.А., Лещев С.В., Александров А.В. Развитие идеи корпоративных информационных пространств как ответ на новую информационную парадигму. // Программные продукты и системы. - 2008. - № 1. - С. 35.
КАРКАСНАЯ БИБЛИОТЕКА КЛАССОВ ДЛЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ
М.С. Кочеров, к.т.н. (НИИ «Центрпрограммсистем», г. Тверь, ppchaos@mail.ru)
Ключевые слова: объектно-ориентированное программирование ние знаний.
Применение объектно-ориентированного подхода (ООП) к проектированию программного обеспечения (ПО) автоматизированных систем организационного управления (АСОУ) означает построение описания предметной области в виде объектной модели, состоящей из системы классов, основанных на принципах инкапсуляции, полиморфизма и наследования. Таким образом, объектная модель предметной области становится важным артефактом проектирования АСОУ наряду с реляционной, поддерживаемой БД.
Рассмотрим стратегию проектирования ПО АСОУ, характеризующуюся: а) наличием объектной модели, полностью описывающей всю предметную область, причем прикладная обработка данных реализуется только на базе этой модели; б) полной изоляцией объектной модели от реляционной (в реализации классов исключены все операции работы с БД). Данная стратегия позволяет в полной мере реализовать все достоинства ООП [1,2] (многократное
, объектная модель, каркасная библиотека классов, представле-
использование кода, распределение разработки, обеспечение эволюционного метода разработки и т.д.), а также обеспечить независимость ПО от используемой БД [3].
Придание объектной модели ключевой роли в проектировании ПО в условиях промышленного производства обусловливает требование унификации процесса построения этой модели, введения в практику программирования четко обозначенных этапов с регламентированной методикой их выполнения. Данную задачу решает каркасная библиотека классов. В качестве теоретической базы реализации библиотеки принят аппарат многосортного исчисления предикатов первой ступени, используемый для синтеза логических моделей представления знаний [4]. Концептуальное представление библиотеки приведено в виде иМЬ-диаграммы классов на рисунке.
Рассмотрим основные моменты, связанные с использованием этой библиотеки. Ключевым элементом библиотеки является класс ТВа$еОЪ]ес1. При по-
TBaseObjectReference
+Указывает на
* 0..1
V
TBaseObject
«metaclass» TBaseObjectClass
7\
+Ссылается на 1
0.. 1 0.. 1
Ж
+Размещается в
TClassDescriptor
Ж
+Ссылается на
«metaclass»
TRoleCollectionItemClass
TRoleCollectionItem
+Входит в
Ж
TRoleCollection
1
0.. 1
ж
«metaclass»
TRoleCollectionClass
+Содержится в
TClassDescriptorsManager
+Управляет
1
0.. 1
TSerializer
TIdProvider
0.. 1
+Относится к
TRcIndices
TRcIndex
0.. 1
1
TNotificationProperties
0.. 1
ж
+Управляет
TRoleCollectionElement
TRoleCollectionsManager
7N
1
+Относится к
0.. 1
+Ссылается на
Ж
TNotificationProperty
*
1
*
1
*
*
строении объектной модели каждая сущность предметной области должна быть описана предметным классом, унаследованным от ТВа$еОЪ]ва. Каждый такой класс будет иметь целочисленное свойство Ы, служащее для уникальной идентификации всех его объектов. Для представления полного множества объектов какого-либо предметного класса разрабатывается класс-коллекция, наследуемый от ТЯо1е-Со11есйоп, и соответствующий класс-контейнер, наследуемый от ТКо1еСо11есйопиет. Каждый объект класса-контейнера предназначен для хранения одного объекта соответствующего предметного класса и входит в объект класс-коллекция. Например, если ТУеЫс1е - это предметный класс для описания транспортных средств, тогда объект класса ТУеЫс^, унаследованного от ТКо1еСо11есйоп, является коллекцией объектов ТУеЫс1е, то есть содержит множество контейнеров - объектов класса ТУеНЫеЬет, унаследованного от ТКо1еСо11есйопиет, в структуру которых входит объект ТУеЫс1е.
Унифицированный доступ к множеству всех коллекций объектов обеспечивается глобальным объектом класса TRoleCollectionsManager. Для этого для каждой коллекции TRoleCollection создается объект TRoleCollectionElement, среди прочего обеспечивающий ее автоматическую инициализацию при первом обращении к ней в программе. Важным применением TRoleCollectionsManager является реализация механизма ссылок на объекты предметных классов, реализуемого через разработку потомков TBaseOЪjectReference. Каждый потомок предназначен для поиска объектов одного из предметных классов по значению их свойств в соответствующей коллекции, доступ к которой обеспечивается через TRoleCollectionsManager.
Таким образом, построенная по этим принципам объектная модель предметной области будет состоять из множества коллекций TRoleCollection, каждая
из которых является машинной реализацией либо некоторого сорта, либо функции (предиката) сигнатуры Е логической модели. Для реализации функций (предикатов) используется следующая техника. Пусть TDrivers - коллекция, описывающая состав водителей транспортных средств, то есть содержащая объекты TDriverltem, каждый из которых имеет объект предметного класса TDriver. Тогда коллекция TDriverVehicles объектов предметного класса TDri-verVehicle, содержащих ссылку на объект TDriver и объект TVehicle, реализует функцию f: Drivers^Ve-hicles, где Drivers - сорт, реализуемый TDrivers, а Vehicles - сорт, реализующий TVehicles. Очевидно, что формулы, которые должны быть истинными в любой структуре, интерпретирующей Е, обнаруживают себя в реализации предметных классов.
Заметим, что реализация ПО на базе таких объектных моделей сопряжена с падением производительности программ при обработке больших объемов информации, свойственных АСОУ [3]. Действительно, в процессе выполнения программы в памяти формируются коллекции большой мощности, доступ к элементам которых (объектам предметных классов) требуется по различным комбинациям их свойств. В каждом конкретном случае возможно решение этой проблемы в индивидуальном порядке, однако в рассматриваемых условиях востребован унифицированный подход, который обеспечивается механизмом автоматического ведения произвольного числа индексов для коллекций. Данный механизм, в свою очередь, базируется на механизме уведомляющих свойств (notification properties) предметных классов. При каждом изменении такого свойства у некоторого объекта, хранящегося в коллекции, осуществляется информирование соответствующего контейнера этого объекта и далее самой коллекции, встроенные методы которой обеспечивают перестройку индекса, связанного с этим уведомляющим свойством. Каж-
дый предметный класс может содержать произвольное число уведомляющих свойств, на подмножестве которых могут быть организованы индексы. По умолчанию для каждого предметного класса свойство Ы является уведомляющим, а каждая коллекция имеет индекс по этому свойству.
Информация о составе уведомляющих свойств (ТМоПАсаПопРтреШе.^) и индексах коллекций (ТЯс-Indices) хранится в дескрипторах классов - объектах ТС1а,^Ве,^спр1ог, множество которых управляется глобальным объектом TClassDescriptorsManager. Как следует из диаграммы, для каждого класса X, унаследованного от ТВа8еОЪ}еа, ТКо1еСо11есйоп или ТКо1еСо11есйопиет, существует собственный дескриптор, создаваемый автоматически при порождении первого экземпляра класса X, что обеспечивается реализацией ТВа8еОЪ}еа, ТКо1еСо11есйоп и ТЯо1е-СоИесйопиет. Последующая инициализация дескриптора для класса X обеспечивается вызовом виртуальных функций классов ТВа8еОЪ}еЛ, ТЯо1е-СоИесйоп или ТКо1еСо11есйопиет, переопределяемых в X.
Упомянутая ранее инициализация коллекций обеспечивается механизмом синхронизации, предусматривающим разработку для каждого предметного класса синхронизатора - потомка TSerializer. Назначение синхронизаторов - загрузка объектов коллекции из БД и их обратная запись, то есть синхронизация объектной и реляционной моделей (таким образом механизм синхронизации обеспечивает требуемую изоляцию объектной модели от реляционной). Информация о синхронизаторе для каждого предметного класса также хранится в соответствующем дескрипторе.
Как уже упоминалось, в каждом предметном классе имеется свойство И. В логику конструктора ТВа8еОЪ}еЛ заложена автоматическая инициализация свойства И, реализуемая на основе механизма
поставщиков идентификаторов. Каждый поставщик - это объект класса, унаследованного от TIdProvider и переопределяющего виртуальный метод getId (обеспечивает возврат очередного идентификатора). Логично, что поставщик идентификаторов должен иметь их централизованный источник. Одним из решений является использование глобального счетчика целых чисел, размещаемого в БД. Для борьбы с издержками, связанными с частым обращением за новыми идентификаторами к этому счетчику, целесообразно применять упреждающее резервирование их некоторого диапазона в начале выполнения программ и далее повторять это по мере надобности. Информация о поставщике идентификаторов для каждого предметного класса хранится в соответствующем дескрипторе.
Описанная библиотека применялась при проектировании ПО в среде Borland Delphi/Kylix, осуществлявшегося на этапе опытно-конструкторской работы по созданию многофункциальной АСОУ, выполняемой НИИ «Центрпрограммсистем» (г. Тверь). Полученные результаты показали целесообразность ее применения на следующих этапах данной ОКР. Дальнейшее развитие библиотеки включает реализацию логического вывода и разработку языка для выполнения информационно-справочных запросов по данным объектной модели.
Литература
1. Грехэм И. Объектно-ориентированные методы. Принципы и практика. - М.: Изд-во «Вилльямс», 2004. - 880 с.
2. Пуха Ю. Объектные технологии построения распределенных информационных систем. // Системы управления базами данных. - 1997. - № 3. - С. 4-20.
3. Fowler M., Rice D. Patterns Of Enterprise Application Architecture. Addison Wesley, 2003. Р. 560.
4. Искусственный интеллект. В 3-х кн. - Кн. 2. Модели и методы: Справочник. / Под ред. Д.А. Поспелова. - М.: Радио и связь, 1990. - 304 с.
ПРИМЕНЕНИЕ НЕЙРОННЫХ СЕТЕЙ ДЛЯ КРАТКОСРОЧНОГО ПРОГНОЗИРОВАНИЯ ЭЛЕКТРОПОТРЕБЛЕНИЯ
В.Н. Зуев (НИИ«Центрпрограммсистем», г. Тверь, zvn_tver@mail.ru); В.Ф. Комиссарчик, к.т.н.; А.Н. Киселев (Тверской государственный технический университет)
Ключевые слова: нейронные сети, система прогнозирования объема электроэнергии, временной ряд.
Плата за электроэнергию, потребленную промышленным предприятием, существенно зависит от отклонения фактических значений электропотребления от договорных (заявленных), поскольку, согласно правилам определения стоимости электрической энергии, предусмотрены штрафные санкции, обусловленные величиной этих отклонений. Таким образом, для принятия решений при планировании заявки на электроэнергию необходимо спрогнозировать режимы электропотребления. Информация по корректировке планового почасового потребления
электроэнергии при наличии действующей автоматизированной системы коммерческого учета электроэнергии предоставляется не позднее, чем за 3 рабочих дня (до 17.00) до даты, с которой предполагается изменение. Таким образом, возникает задача суточного прогнозирования электропотребления на трое суток вперед с максимально возможной точностью.
В данной работе рассматривается программная система прогнозирования объема электроэнергии, потребляемой стеклозаводом, с использованием ней-росетевого прогнозатора.
