CC BY
56
Общий алгоритм предоставления услуги по подбору музыкальных композиций имеет следующую последовательность действий: клиент должен авторизоваться на сайте, затем идет проверка правильности ввода данных, после этого клиент переходит на страницу, где расположена форма для построения списка музыкальных композиций. На странице клиенту предлагаются вопросы о его целевой аудитории и вида товара в магазине, для которого формируется плейлист.
После обработки ответов система выводит на экран плейлист с композициями, если клиента он устраивает, то отчет высылается офис-менеджеру радиостанции «Парнас», который назначает музыкального редактора для дальнейшей обработки плейлиста. Клиенту же необходимо заполнить регистрационную форму для ввода более точной информации о фирме, при помощи которой музыкальный редактор сможет более точно подобрать музыкальные композиции. Затем клиенту на почтовый адрес отсылается предварительный плейлист, и если его все устраивает, он посылает положительный ответ. На стороне офисменеджера происходит расчет цены плейлиста, оформление договора с РАО. Клиенту назначается дата и время, когда он сможет прийти в офис и оплатить услугу, затем ему выдается готовый плейлист и лицензионное соглашение с РАО.
Рис. 3 - Схема взаимодействия подсистемы поддержки принятия решений с компонентами ИС
Таким образом, разрабатываемая информационная система позволит подобрать музыкальные композиции в соответствии с целевой аудиторией и использовать их с соблюдением авторских прав, а также разместить предварительный плейлист в сети Интернет, что позволит получить дополнительную прибыль и увеличить конкурентоспособность фирмы.
Литература
1. Milliman R. E. Using background music to affect the behavior of supermarket shoppers //Journal of Marcetting // <http://en.academic.ru>.
2. Кузнецов С.Д. СУБД (системы управления базами данных) и файловые системы.- М: Майор, 2001 г.
УДК 004.438, 004.08, 004.274
ОА-АРХИТЕКТУРА - НОВЫЙ ПОДХОД К СОЗДАНИЮ ОБЪЕКТНЫХ СИСТЕМ1
Салибекян Сергей Михайлович, ст. преподаватель, Московский институт электроники и математики (технический университет), Россия, Москва, salibek@yandex.ru Панфилов Пётр Борисович, к.т.н., доцент, Московский институт электроники и математики (технический университет), Россия, Москва, panfilov@miem.edu.ru
1 Статья рекомендована к опубликованию в журнале "Информационные технологии"
74
В настоящей статье предлагается новый подход к построению объектных систем -объектно-атрибутная (ОА) архитектура вычислительной системы (ВС), разработанная автором [1,2]. Данный подход обладает намного большими возможностями для объектного программирования и создания интеллектуальных систем, чем общепринятое в настоящее время объектно-ориентированное программирование (ООП) и реализует принцип управления вычислительным процессом с помощью потока данных (dataflow).
Объектно-атрибутная (ОА) архитектура основывается на ряде понятий:
Информационная пара (ИП) (атрибутированные данные) - совокупность нагрузки (данных или ссылки на данные), и ярлыка/атрибута (уникального идентификатора), описывающего нагрузку.
Функциональное устройство (ФУ) - это виртуальное (реализованное программным способом) или реальное устройство, осуществляющее обработку данных. ФУ имеет внутренние регистры (набор регистров будем называть контекстом ФУ) и может исполнять некий набор милликоманд, описываемый алгоритмом функционирования этого устройства.
Милликоманда (мК) - это ИП, где ярлык указывает устройству (ФУ), каким образом следует обрабатывать прикрепленные к нему данные.
Капсула - это множество информационных пар, служащих для описания определенного объекта (с помощью капсулы и обеспечивается абстракция данных). Каждая ИП, входящая в капсулу, задаёт один из критериев описываемого объекта.
Например: Параллепипед {Длина=10 Высота=15 Ширина=20}, где {} - данные знаки задают начало и конец описания капсулы; = - знак сопоставления атрибута и информационной нагрузки; Параллепипед - имя информационной капсулы.
Кроме того, в качестве нагрузки в ИП может выступать не только константа, но и ссылка на переменную, капсулу или иную информационную структуру, благодаря чему появляется возможность синтезировать смысловой граф, состоящий из множества капсул, связанных ссылками. Смысловой граф служит для описания сколь угодно сложного объекта подобно тому, как это делается в объектно-ориентированном программировании (ООП) (рис. 1). Капсула может содержать не только данные, но и программу (миллипрограмму), которая состоит из последовательности милликоманд, помещенных в капсулу. Данный подход обладает намного большей гибкостью, чем фреймовая модель, т.к. механизм капсул и ссылок в качестве нагрузок ИП чем-то напоминает детский конструктор, из которого можно собрать какую угодно информационную конструкцию в реальном времени.
О А вычислительная система Дерево абстракций
Рис. 1 - Работа ВС с ОА-деревом абстракций
ОА-Дерево абстракций (или смысловой граф) несколько напоминает собой структуру класса в объектно-ориентированном программировании (ООП), однако здесь существует одно весьма важное отличие. Как известно, ООП было строено на основе фреймовой концепции (концепция была разработана Марвином Минским в 70-е годы прошлого века [3]): фреймовая модель была лишь дополнена возможностью ссылки не только на другой фрейм, но и на процедуру или функцию (методы класса объектов). Совокупность фреймов, связанных между собой ссылками, хоть и дает возможность описывать любые реальные или абстрактные объекты, однако не обладает достаточной гибкостью, чтобы изменять свою
75
структуру непосредственно во время выполнения вычислительного процесса: как правило, фреймовая структура (в ООП классы объектов) создаются ещё до начала выполнения программы и далее не меняются. В ОА-архитектуре используется совершенно другой подход: информационные структуры, описывающие объекты, синтезируются уже во время работы ВС по заранее заложенным программистом (или экспертом) правилам: информационные структуры, образуются путем группировки ИП в капсулы и настройки ссылок между капсулами (синтез дерева абстракций - см. рис. 1).
Синтезом ОА-графа и его анализом занимаются ФУ, использующие новую (милликомандную) командную систему (или ОА-язык). Обмен информацией между ФУ осуществляется через шину данных-атрибута (ТТТДА), по ней передается милликоманда с нагрузкой (константой или ссылкой на иную информационную конструкцию) (рис. 1). По атрибуту милликоманды ФУ идентифицирует данные, пришедшие к нему по ТТТДА, и, исходя из атрибута, принимает решение, каким образом ему следует их обрабатывать. Каждое ФУ имеет набор внутренних регистров (контекст), который используется для хранения промежуточных данных.
Например, ФУ АЛУ (арифметико-логическое устройство) имеет следующий контекст: аккумулятор, флаг нулевого результата и флаг знака результата. Для выполнения операции сложения на Шину необходимо выдать следующую последовательность милликоманд, описанных на ОА-языке:
Bus {ALU.Set=2, ALU.Add=2, ALU.Put=x},
где Bus - указание на то, что последовательность милликоманд, расположенных в капсуле, должна быть выдана на Шину; = - знак сопоставления ярлыка и нагрузки; ALU - имя ФУ; ALU.Set, ALU.Add, ALU.Put - расширенные милликоманды для устройства АЛУ (расширенная милликоманда - это милликоманда, в которой указывается ФУ, что должно милликоманду исполнять: перед точкой стоит обозначение ФУ, которому передается милликоманда, после точки - ярлык передаваемой нагрузки): ALU.Set - записать число из нагрузки милликоманды в аккумулятор, ALU.Add - сложить значение из аккумулятора с числом из нагрузки и записать результат вычисления обратно в аккумулятор, ALU.Put -записать значение из аккумулятора в ячейку памяти, хранящуюся в нагрузке милликоманды; x - ячейка памяти, куда АЛУ выдает результат своих вычислений.
ФУ могут быть реализованы как программным, так и аппаратным способом, поэтому ОА-язык одновременно является и языком высокого, и языком низкого уровня.
Например, при программной реализации ФУ алгоритм работы АЛУ можно оформить с помощью следующей процедуры на языке C:
void ALU(void * Context, int millicomand, void *Obj),
{
switch millicomand case {
case 0: // Сброс (Сброс)
// - в скобках указана мнемоника милликоманды PAluContext(Context)-> Accumulator=0; case 1: // Установить значение в аккумуляторе (Уст) if(Obj==nil) PAluContext(Context)-> Accumulator=0; else PAluContext(Context)-> Accumulator=PVariant(Obj); case 2: // Сложение (Сум) if(Obj<>nil)
{
PAluContext(Context)->Accumulator=PAluContext(Context)-> Accumulator+PVariant(Obj);
if(PAluContext(Context)-> Accumulator>=PVariant(Obj))
FLager=true;
else FLager=false;
if(PAluContext(Context)-> PVariant(Obj)==0)
FZero=true;
else FZero=false;
}
76
case 4: // Выдать содержимое аккумулятора (Выд) if(Obj<>nil)
PVariant(Obj)=PAluContext(Context)->Accumulator;
}
// и т.д.
}
где Context - ссылка на контекст ФУ, т.е. на структуру данных, которая содержит виртуальные регистры (таким образом с помощью одной процедуры реализации логики работы ФУ можно управлять сразу несколькими ФУ лишь меняя адрес в параметре Context);
millicomand - индекс милликоманды (по данному индексу ФУ определяет тип данных и их назначение;
Obj - ссылка на нагрузку милликоманды (данная ссылка может указывать как на переменную, так и на любую информационную конструкцию). Ввиду того, что логика работы ФУ довольно проста, не будет особого труда реализовать их не только в программном исполнении (виртуальные ФУ), но и в аппаратном.
Данный интерфейс, состоящий из трёх полей, одинаков для всех типов ФУ, что обеспечивает полную универсальность вызова процедуры реализации логики работы ФУ (в отличие от классических процедур и функций, которые имеют свой индивидуальный интерфейс - перечисление передаваемых и возвращаемых параметров).
Для полноценного же функционирования ОА-системы необходимо ввести ФУ нескольких типов: Шина - специализированное ФУ, которое обеспечивает передачу ИП между различными ФУ, АЛУ, ДиспетчерКапсул - создание, удаление и модификация ИП, группировка ИП в капсулы, УстройствоВводаВывода, ДиспетчерСписков - осуществляет формирование списков и поиск по списку, исходя из заданных условий, МатричноеАЛУ и Автомат т.д. Например, ФУ Автомат предназначен для того, чтобы выдавать на ШДА последовательность милликоманд, расположенных в капсуле. На рис. 2 представлен фрагмент капсулы с миллипрограммой, которая задает вывод результата вычисления ФУ АЛУ на консоль (экран).
На первом такте считывающая головка Автомата (указатель на адрес текущей выдаваемой на ШДА милликоманды) находится на милликоманде ALU.Put=temp («записать результат вычислений в ячейку памяти с адресом temp»). Причем temp - это адрес нагрузки следующей милликоманды); OutConsole.Put=temp(0), где temp задает ссылку на нагрузку, (0) - указывает начальное значение, хранимое в нагрузке. На первом такте Автомат считывает первую милликоманду и выдает ее на Шину; Шина передает милликоманду на устройство ALU; а ALU записывает результат вычисления в ячейку памяти, адрес которой записан в нагрузке милликоманды, т.е. в temp (нагрузку следующей милликоманды). На втором такте работы Автомата указатель (считывающая головка) передвигается на следующую милликоманду и далее вторая милликоманда выдается Автоматом на Шину; Шина передает ее на ФУ OutConsole, которое считывает из нагрузки значение, записанное на предыдущем такте ALU, и выводит его на консоль. Следует отметить, что в нагрузке может храниться адрес не только переменной, но и любой информационной конструкции (массива, графа абстракций и т.д.). Тип данных, на который ссылается указатель, ФУ определяет по ярлыку:
77
например, ярлык может быть «Первое слагаемое целого типа», «Первое слагаемое - число с плавающей точкой» и т.п.
ОА-арихитектура в полном объеме обеспечивает принцип управления вычислительным процессом с помощью потока данных: в ОА-системе даже можно обойтись без привычного для классической парадигмы программирования оператора условного перехода (if). Как несложно заметить, ФУ управляются не командами извне, а именно потоком данных, ведь милликоманда по сути является атрибутированными данными, а решение о том, каким образом данные обрабатывать, принимает само ФУ (ФУ выполняет операцию в том случае, когда к нему приходят все необходимые для выполнения операции данные). К тому же, различия между данными и программным кодом стирается благодаря тому, что в ОА-архитектуре полностью совпадают форматы данных и программы: милликоманда - это, по сути, та же ИП, а миллипрограмма - это капсула с набором ИП. Поэтому капсулы с миллипрограммой можно без труда встраивать в ОА-граф, превращая его в мощную базу знаний. В ООП же в основном применяется управление с помощью команд (методы, входящие в классы объектов, представляют собой последовательность команд), что существенно ограничивает гибкость ВС.
К преимуществам разработанной архитектуры можно отнести удобный способ абстракции данных и программного кода, используемый не только для описания, но и для распознания объектов: абстракции не создаются заранее перед выполнением программы, как в ООП, а синтезируются по заранее описанным правилам уже в процессе выполнения программы, что существенно повышает гибкость вычислительного процесса; это позволит наделить ОА-систему полноценным интеллектом: в результате появляется возможность описания/распознания заранее неизвестных программисту объектов и самообучения ВС (т.е. самостоятельное изменение системой правил синтеза информационных конструкций). Синтез же информационных конструкций в ОА-архитектуре осуществляется от простого к сложному: ОА-система распадается на несколько уровней абстракции. Процесс начинается с так называемых информационных атомов - элементарных (неразложимых) абстракций (атом в большинстве случаев представляет собой единственную ИП). Так, для систем автоматизации атомами будут являться сигналы, считанные с датчиков и снабженные ярлыками, идентифицирующими их. Для систем распознавания изображений атомы -описания отдельных пикселов изображения (координаты и код цвета). Для систем смыслового анализа текста атомами будут являться отдельные символы, составляющие анализируемый текст (рис. 3). Например, при смысловом анализе текста на первом уровне абстракции происходит лексический анализ, т.е. формирование слов из символов.
Формированием информационных конструкций для передачи на более высокий уровень абстракции занимаются ФУ, которые реализуют алгоритм первого уровня абстракций. Далее выделенные слова, оформленные в виде информационной капсулы или ОА-графа передаются на следующий уровень абстракции, где происходит синтаксический анализ. Информационные конструкции, сформированные на этом уровне, передаются на уровень выше для смыслового анализа и т.д. На каждом последующем уровне информационные конструкции (абстракции) становятся все более и более сложными и их количество уменьшается (сложная абстракция представляет собой довольно большой смысловой граф). На вершине этого так называемого конуса абстракций находится ключевая абстракция, описывающая распознаваемый объект полностью. Если же необходимо из общей абстракции произвести синтез более простых информационных конструкций, то применяется обратный конус абстракций (т.е. синтез от сложного к простому). Так, если требуется перевести текст с одного языка на другой, то используются сразу и прямой (распознание смысла исходного языка), и обратный (для синтеза текста уже на другом языке) конусы абстракций (рис. 3). ОА-конус абстракций весьма легко реализуется на распределенной ВС: части конуса абстракций относительно независимы друг от друга и их можно расположить на различных вычислительных узлах (рис. 3). К тому же, в отличие от распространенных интерфейсов Corba и DCOM, в ОА-системе нет необходимости описывать
78
шаблоны интерфейсов удаленных процедур (язык IDL), т.к. все параметры для ФУ передаются по отдельности в виде милликоманд, что значительно облегчает процедуру обмена информацией между вычислительными узлами.
Разработанная архитектура в полной мере поддерживает принцип изоморфизма (безболезненного изменения программы), т.к. любую классическую процедуру возможно реализовать с помощью ФУ: параметры такой процедуры передаются посредством милликоманд. ФУ для других участников информационного процесса представляет собой «черный ящик», общаться с которым можно с помощью милликоманд, поэтому модификация ФУ заключается в расширении набора милликоманд (для совмещения со старыми версиями программ алгоритм работы ФУ следует модернизировать таким образом, чтобы не изменять функционал милликоманд старых), потому изменение количества операндов и последовательность их передачи для ФУ не будут критически влиять на всю ОА-программу. В классических же процедурах и функциях параметры передаются единовременно, и при изменении интерфейса (перечня параметров) процедуры или функции программисту приходится исправлять всю программу. Во-вторых, любое ФУ очень легко заменить с помощью так называемого Интерпретатора. Интерпретатор представляет собой заглушку, которая переводит последовательность милликоманд для старого типа ФУ в последовательность милликоманд для одного или нескольких новых ФУ. Изоморфизм обеспечивается и на уровне структур данных: модификация ОА-графа, заключающаяся в добавлении в информационные капсулы новых ИП, что не влияет на алгоритмы поиска по графу для других ФУ. Изоморфизм, который обеспечивает ОА-архитектура, не только помогает облегчить труд программиста, но и является необходимым качеством для создания интеллектуальных систем, ведь в процессе распознания объектов программе приходится довольно существенно изменять базу знаний и модификации эти не должны нарушать целостности ВС.
Рис. 3 - Прямой и обратный конусы абстракций
Работоспособность предложенной архитектуры подтверждается тем, что в настоящий момент создана программная платформа ОА-среды. В среде реализованы 35 классов ФУ, ОА-язык программирования (компилятор ОА-языка реализован на базе ОА-архитектуры); имеется возможность не только программирования, но и управления ОА-системой в реальном времени, то есть коррекция алгоритма работы системы без перезагрузки ОА-программы.
В заключение можно отметить следующие положительные стороны ОА-архитектуры:
• удобная структуризация (абстракция) как данных, так и программы;
• изоморфизм;
• обладает «врождённым» параллелизмом вычислений (каждое ФУ работает асинхронно и потому может работать параллельно с другими ФУ);
• легко реализуется на распределенной вычислительной системе (программист не разрабатывает изолированный код для каждого вычислительного узла системы и
79
затем описывает обмен данными между узлами; а проектирует целостную программу, которая потом будет выполняться на всей распределенной ВС [2]);
• ОА-система реализуется как программно, так и аппаратно;
• при программной реализации обладает легкой переносимостью с одной аппаратной платформы на другую (для того, чтобы ОА-программа заработала на новой аппаратной платформе, необходимо лишь закодировать для новой машины подпрограммы реализации логики работы ФУ);
• обладает хорошей масштабируемостью как на программном, так и на аппаратном уровнях;
• облегчает процесс написания программы: ОА-программа хорошо декомпозируется, части программы весьма легко стыкуются между собой.
Литература
1. Салибекян С.М. Принципы милликомандной архитектуры как основа построения высокопроизводительных адаптивных вычислительных систем // Автоматизация и современные технологии. 2002. № 5.
2. Салибекян С.М., Панфилов П.Б. ОА-архитектура построения и моделирования распределенных систем автоматизации // Автоматизация в промышленности. 2010 №11
3. Минский М. Фреймы для представления знаний: Пер. с англ.- М.: Энергия, 1979.
УДК 004.4
ОПЫТ РЕАЛИЗАЦИИ УНИФИЦИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
УЧЕТА ОКАЗАННЫХ УСЛУГ1
Герасимова Ольга Игоревна, Шахтинский институт (филиал) Южно-Российского государственного технического университета (Новочеркасского политехнического института),
Россия, Шахты, itblack@rambler.ru
Введение
Актуальность данной работы обуславливается тем, что в настоящее время все большее количество организации переходит от ведения учета на бумажных носителях к использованию информационных систем (ИС). Корректно спроектированная и реализованная ИС позволяет сделать процесс учета более быстрым и удобным, одновременно способствуя повышению конкурентоспособности предприятия на рынке.
Проектирование структуры базы данных (БД) - одна из наиболее ответственных фаз реализации программного обеспечения, успех которой во многом зависит от выбранной методологии. В данной работе использована методология сущность-связь, подробно описанная в [1-2]. Этап проектирования БД начинается с установления границ будущей разрабатываемой системы и определения функционала, который необходимо реализовать в приложении. Концептуальное проектирование БД позволяет описать высокоуровневую модель и начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации.
Следующим этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учёта специфики используемой СУБД и прочих условий реализации [1].
1 Лауреат номинации "Лучший доклад по UML-моделированию". Автор доклада награждается книгой Иванова Д. Ю. и Новикова Ф.А. "Моделирование на UML. Теория, практика, видеокурс" (www.umlmanual.ru) с автографами авторов
80
