CC BY
48
ЛПР или группе ЛПР, имеющих общие технические знания.
В примере к данному классу субъектов управления относятся студенты технического университета, обладающие набором знаний, позволяющих выполнить рекомендации.
2. Текстовое сообщение с обоснованием эффективности предложенных вариантов устранения отклонения, построенное на использовании специальных технических терминов, - позволяет выявить и устранить причину возникновения отклонений.
В примере к данному классу относится преподаватель - ЛПР, обладающее набором знаний и компетенций, позволяющих ему адекватно воспринять полученную от системы информацию и исправить ошибки в энергопотреблении.
Данные, полученные от измерительных приборов и обработанные системой, необходимы системному администратору для поддержания эффективности работы системы. Предоставляются оператору в виде развернутых отчетов.
Сообщения, генерируемые системой для каждого из классов, формируются с учетом их атрибутов. Наиболее важными являются набор знаний и компетенций, но также важно учитывать состояние здоровья субъектов управления, т.к. без учета этого атрибута возможно снижение его работоспособности.
Заключение
Унифицированная диаграмма классов для систем энергетического менеджмента позволяет установить виды взаимодействия между программно-техническим обеспечением и ЛПР. Где ЛПР - это субъект управления, т.е. часть системы энергетического менеджмента. Поэтому эффективное функционирование данной системы возможно только при наличии обратной связи от объекта (программно-техническое обеспечение) к субъекту управления (ЛПР) в виде названых выше сигналов.
Литература
1. Иванов С.А., Разработка интеллектуальной системы энергоменеджмента на основе объектноориентированного подхода/ С.А.Иванов, Л.А. Вяль, М.А. Горькавый// Объектные системы 2013: Материалы VII Международной научно-практической конференции, Россия, Ростов-на-Дону 10-12 мая 2013 г., С. 45-50.
2. Болдырев, В.В. Концепция интеллектуального алгоритма автоматизированной системы энергопотребления/ В.В. Болдырев, М.А. Горькавый // Технические и математические науки: актуальные проблемы и перспективы развития: материалы междунар. науч.-практ. конф., Саратов, 14.11.2013г., С. 19 -24.
3. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч; пер. с англ. И. Романовского; под ред. Ф. Андреева - М.: Невский Диалект, 2000. -359 с.
УДК 004.4'236
ФУНКЦИОНАЛЬНАЯ СХЕМА ВСТРОЕННОГО ОБЪЕКТНООРИЕНТИРОВАННОГО ИНТЕРАКТИВНОГО МЕХАНИЗМА КОНСТРУИРОВАНИЯ СТРАНИЦ САЙТА НА ОСНОВЕ МАТРИЧНОЙ УНИВЕРСАЛЬНОЙ ОБЪЕКТНОРЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
Микляев Иван Александрович, к.ф.-м. н., доцент, Институт судостроения и морской арктической техники (Севмашвтуз) Северного (Арктического) федерального университета имени М. В. Ломоносова, Россия, Северодвинск, ivanmia1@rambler.ru Юрецкий Алексей Павлович, студент, Институт судостроения и морской арктической техники (Севмашвтуз) Северного (Арктического) федерального университета имени М. В. Ломоносова, Россия, Северодвинск, admin@webprogrammist.su
Введение
26
При разработке сайтов для ускорения и формализации процесса используются различные виды программ:
1. Среды визуальной разработки, например, Dreamweaver [1], FrontPage [2].
2. Интегрированные среды разработки (IDE), например Zend Studio [3], Delphi for PHP [4].
3. Среды веб-разработки - системы управления сайтом (CMS), например 1C-Bitrix [5], Wordpress [6].
Разработка встроенного объектно-ориентированного интерактивного механизма конструирования страниц сайта (ВОИМКСС) на основе матричной универсальной объектнореляционной базы данных (МУОРБД) [7] преследует цель создание интегрированной вебсреды визуальной разработки сайтов, как доступной пользователям, не имеющим специальных знаний в сфере веб-разработки, так и подходящей в качестве мощного инструмента для профессиональных разработчиков, обеспечивающей гибкость в возможностях настройки дизайна, не ограниченную использованием стандартных шаблонов, обеспечивающую широкий спектр функционала, доступного для расширения непосредственно разработчиком, лёгкость развёртывания на хостинге и простоту переноса сайта.
1. Прикладное применение МУОРБД для размещения структуры сайтов
Формирование древовидного представления информации, содержащейся в базе данных, позволяет проводить любые динамические изменения и расширения структуры.
МУОРБД развёрнута на платформе MySQL. Все действия с информацией структуры сайта, размещённой в МУОРБД, позволяет задействовать весь механизм как самой МУОРБД, так и инструментарий реляционной платформы [8].
Очевидным является в условиях реальной разработки использование интерактивной среды, что ещё в 1990-е годы показало значительное преимущество. Оптимальным решением для быстрой и наглядной разработки является способ редактирования, который получил название WYSIWYG (от англ. What You See Is What You Get — «что видишь, то и получишь»), при котором корректируемый материал в процессе редактирования выглядит в точности так же, как и конечный результат. Для осуществления этого способа редактирования МУОРБД-сайтов разработан ВОИМКСС.
Визуально ВОИМКСС представляет собой комплекс интерактивных элементов, расположенных в слое над слоем страницы. ВОИМКСС, в отличие от ныне существующих систем, имеет прямую связь с древовидной структурой информации, которая размещается в МУОРБД. МУОРБД-ключ, который присваивается каждому элементу страницы, показывает адрес данного элемента в древовидной структуре.
2. Организация ВОИМКСС
ВОИМКСС имеет сложную организацию с множеством логических ветвлений. Для упрощения работы и понимания происходящих процессов была разработана структура переменных и функций. Она позволяет в любой точке исполняемого кода иметь либо получать необходимые данные о состоянии системы. Тем самым оптимизируется процесс модернизации, расширения и верификации исполняемого кода ВОИМКСС и его дальнейшая работа на уровне пользователя.
ВОИМКСС функционирует на стороне клиента. Обмен данными с сервером осуществляется через технологию межъязыкового взаимодействия Ajax.
3. Описание механизма взаимодействия
После того, как пользователь авторизовался на странице для её редактирования, страница перегружается в окне браузера, неся с собой функционал ВОИМКСС. (см. рис. 1 -начальное псевдосостояние «Начало»).
27
В состав функционала из справочной сущности МУОРБД генерируются заданные массивы возможных действий и состояний системы. Сразу после того, как загрузится скрипт, активируются функции перехвата событий и система находится в состоянии ожидания наступления события (см. рис. 1 - сущность «Ожидание наступления события», переход «Передача сигнала об отсутствии события»). Теперь все действия пользователя в браузере контролируются программой.
Рис. 1 - Схема взаимодействия структурных элементов ВОИМКСС Когда пользователь выполняет действие на странице браузера (см. рис. 1
переход
28
«Передача сигнала о произошедшем событии»), начинает работу соответствующая функция перехвата событий (см. рис. 1 - сущность «Перехват события»). В первую очередь извлекается информация о том, на каком элементе произошло событие, создаётся клон элемента объектной модели браузера и заносится его в глобальную хеш-переменную «Активный объект» (см. рис. 1 - переход «Инициализация активного объекта», сущность «Активный объект»), а также запрашиваются данные в массивах хранения параметров состояния системы и состояний возможных действий (см. рис. 1 - переходы «Запрос данных в массиве хранения параметров состояния системы», «Запрос данных в массиве хранения состояний возможных действий», сущности «Массив хранения параметров состояния системы», «Массив хранения состояний возможных действий»).
Отдельным случаем является событие «onclick» на главных управляющих элементах -кнопках «Выход» и «Просмотр / Редактирование». Обработка этих событий осуществляется вне основной схемы. В случае нажатия на кнопку «Выход» осуществляется завершение работы ВОИМКСС и перегрузка страницы без его функционала. Кроме того, в серверной части программы запускается система сохранения изменений страницы сайта и происходит уничтожение сессии, которая хранит авторизацию пользователя на текущей странице для её редактирования (см. рис. 1 - сущность «Проверка условий», переход «Выполнение выхода», конечное псевдосостояние «Выход»).
При первоначальной загрузке функционала ВОИМКСС переменная-флаг, хранящая метку о глобальном состоянии системы, получает значение «False», что соответствует состоянию просмотра страницы. Нажатие кнопки «Просмотр / Редактирование» меняет значение этого флага на противоположное. После чего происходит формирование соответствующего флагу представления интерфейса пользователя (см. рис. 1 - переход «Получение параметров активного объекта», сущность «Проверка условий», переход «Передача управления в блок ожидания и перехвата событий»), в котором изменяется подпись кнопки «Просмотр / Редактирование», отображаются панель компонентов и панель атрибутов. Далее система вновь находится в состоянии ожидания наступления события.
В остальных случаях, исходя из текущих параметров состояния системы, состояния возможных действий и данных об активном объекте (см. рис. 1 - сущности «Массив хранения параметров состояния системы», «Массив хранения состояний возможных действий», «Активный объект», переходы «Передача текущих параметров состояния системы», «Передача текущих состояний возможных действий», «Передача параметров активного объекта»), управление передаётся в соответствующий блок функций, где в дальнейшем протекает предопределённый процесс (см. рис. 1 - переходы «Передача управления в блок функций редактирования объекта», «Передача управления в блок функций формирования интерфейса пользователя», «Передача управления в блок функций работы с сервером через механизм Ajax»).
Общая деятельность системы не зависит от внутреннего содержания любого из блоков функций ВОИМКСС, а определяется лишь выбором из них, передаваемой и получаемой информацией. Таким образом, блоки функций могут расширяться неограниченно. Структура передаваемой и получаемой информации одинакова для всех вызываемых функций одного блока; для функций различных блоков отличается.
Передача управления функции из блока формирования представления интерфейса пользователя - первый вариант хода логической цепочки (см. рис. 1 - переход «Передача управления в блок функций формирования интерфейса пользователя», сущность «Формирование представления интерфейса пользователя») частично был описан выше, когда речь шла о формировании соответствующего флагу интерфейса пользователя.
На выходе из предопределённого процесса формирования представления интерфейса пользователя передаются данные об изменённых параметрах состояния системы, которые фиксируются в массиве хранения параметров состояния системы, и передаётся управление в блок ожидания и перехвата события (см. рис. 1 - переходы «Передача изменённых параметров состояния», «Передача управления в блок ожидания и перехвата событий»).
29
В данном случае изменения не затронут редактируемую страницу. Данные на сервере также не будут изменены. Изменится только внешнее отображения интерфейса ВОИМКСС.
Если кликнуть на какой-либо элемент страницы, происходит событие «ondick», в результате которого клон объекта помещается в локальную переменную «Активный объект». Здесь исключена обработка событий на кнопках «Выход» и «Просмотр / Редактирование», поэтому работа механизма идёт по основному направлению логической цепочки схемы. Система запущена на редактирование, поэтому далее идёт проверка по условиям. Далее происходит вызов функции, соответствующей данным условиям, которая относится к блоку формирования представления интерфейса пользователя.
В результате работы функции происходит изменение интерфейса пользователя, а именно: скрывается панель компонентов; происходит выделение активного элемента; появляется панель с атрибутами и параметрами выбранного элемента (Object Inspector).
После выполнения функции из блока формирования представления интерфейса пользователя происходят соответствующие изменения в массиве хранения параметров состояния системы. Панель компонентов помечается как скрытая; Object Inspector помечается как отображаемый.
Далее система опять возвращается в состояние ожидания события.
Передача управления функции из блока функций редактирования объектов - второй вариант хода логической цепочки, основой (см. рис. 1 - переход «Передача управления в блок функций редактирования объекта», сущность «Выполнение редактирования объекта»). Перед началом выполнения предопределённого процесса редактирования объекта вносятся изменения в массив хранения возможных состояний системы - фиксируется старт действия, которое запускается вызовом функции, выбранной в соответствии с текущими условиями (см. рис. 1 - переход «Передача сигнала о старте действия»). На выходе из предопределённого процесса редактирования объекта происходит несколько действий:
1. Изменяется активный объект (см. рис. 1 - переход «Передача изменённых данных в активный объект»).
2. Происходит передача управления в предопределённый процесс формирования представления интерфейса пользователя (см. рис. 1 - переход «Передача данных в блок формирования представления интерфейса пользователя в процессе изменения объекта»).
3. Происходит передача данных в предопределённый процесс работы с сервером через механизм Ajax (см. рис. 1 - переход «Передача данных на сервер после завершения изменения объекта»).
После завершения предопределённого процесса редактирования объекта, вносятся изменения в систему хранения возможных состояний системы (см. рис. 1 - переход «Передача сигнала о завершении действия») - фиксируется завершение действия, которое было запущено; даётся команда на завершение действия, которая возвращает систему в состояние ожидания события (см. рис. 1 - переход «Передача управления в блок ожидания и перехвата событий»). При движении по этой логической цепочке схемы, происходят изменения, которые в зависимости от вызванной функции могут коснуться редактируемой страницы, данных на сервере или представления интерфейса пользователя.
В качестве примера рассмотрим выполнение действия перемещения элемента страницы.
Перед началом перемещения элемента происходит событие «onmouseover». Клон объекта помещается в локальную переменную «Активный объект». Это событие не «ondick», где необходимо исключать обработку основных функциональных кнопок «Выход» и «Просмотр / Редактирование», значит, работа программы идёт по общему случаю. Система запущена на редактирование, что по логической цепочке схемы ведёт к проверке по условиям. Происходит вызов функции перемещения. Эта функция относится к блоку редактирования объекта.
30
Далее фиксируется старт возможного активного действия «перемещение» в системе хранения возможных действий, а также сохраняется идентификатор перемещаемого объекта.
В процессе перемещения происходит постоянная передача информации в функцию блока формирования представления интерфейса пользователя, которая в режиме реального времени фиксирует изменение параметров перемещаемого объекта (отступ сверху и отступ слева) и отображает эти изменения в Object Inspector.
После завершения перемещения, когда пользователь отпускает кнопку мыши, завершается работа функции перемещения. Одновременно с этим фиксируется завершение активного действия «перемещение» в системе хранения возможных действий и высвобождается идентификатор перемещаемого объекта, вызывается функция из блока работы с сервером через механизм Ajax, которая преобразует параметры перемещённого элемента в необходимый вид и передаёт их на сервер посредством технологии Ajax. Сервер, получив данные, обрабатывает их определённым образом и обновляет изменённые значения в сессии.
Далее система опять возвращается в состояние ожидания события.
Передача управления функции из блока функций работы с сервером через механизм Ajax - третий вариант хода логической цепочки (см. рис. 1 - переход «Передача управления в блок функций работы с сервером через механизм Ajax», сущность «Работа с сервером через механизм Ajax»). На входе в предопределённый процесс используются данные активного объекта, которые преобразуются в необходимый вид и передаются на сервер посредством технологии Ajax. На выходе происходит возврат системы в состояние ожидания события (см. рис. 1 - переход «Передача управления в блок ожидания и перехвата событий»). В данном случае изменений на редактируемой странице и в представлении интерфейса пользователя не происходит. Изменяются данные на сервере.
Например, произведя необходимые изменения на странице сайта и убедившись, что получили то, что необходимо, можно зафиксировать изменения, перенеся их из сессии в базу данных. Для этого, служит кнопка «Сохранить изменения». Происходит событие «onclick». Здесь исключена обработка событий на кнопках «Выход» и «Просмотр / Редактирование», поэтому работа механизма идёт по основному направлению логической цепочки схемы. Система запущена на редактирование, поэтому далее идёт проверка по условиям.
Вызывается функция из блока работы с сервером через механизм Ajax, которая передаёт на сервер сигнал о том, что необходимо зафиксировать произведённые изменения. Сервер, получив этот сигнал, выполняет функцию, которая формирует запросы, в которых заложены внесённые изменения и отправляет их на сервер баз данных.
Далее система опять возвращается в состояние ожидания события.
4. Структурные элементы
Структура ВОИМКСС состоит из двух двухмерных массивов, переменной-хеша и четырёх групп функций, которые объединены в соответствии с выполняемыми действиями.
Таким образом, в ВОИМКСС используются следующие структурные элементы:
• Массив хранения состояний возможных действий - двухмерный массив, содержащий состояния всех возможных (реализованных) на данный момент действий в системе и их параметры (см. рис. 1 - сущность «Массив хранения состояний возможных действий»).
• Массив хранения параметров состояния системы - двухмерный массив, содержащий все необходимые для отслеживания состояния системы в целом, либо отдельных её элементов (см. рис. 1 - сущность «Массив хранения параметров состояния системы»).
• Активный объект - ассоциативный javascript-массив, хеш, содержащий соответствия «ключ» => «значение», и методы, соответствующие реальному объекту, с которым в текущий момент времени производит действие пользователь (см. рис. 1 - сущность «Активный объект»). Функции трансляции-коммуникации. Это группа функций, которые посредством технологии Ajax отправляют на сервер информацию о
31
результатах работы системы и получают необходимые для работы дополнительные данные (см. рис. 1 - сущность «Работа с сервером через механизм Ajax»).
• Функции элементов управления визуальным отображением интерфейса. Это группа функций, которые отвечают за работу элементов управления визуальным отображением ВОИМКСС, то есть обеспечивают интерфейс пользователя (см. рис. 1 - сущность «Формирование представления интерфейса пользователя»).
• Функции редактирования. Это группа функций, которые реализуют возможности интерактивной работы пользователя с элементами редактируемой страницы (см. рис. 1 - сущность «Выполнение редактирования объекта»).
• Функции перехвата событий. Это центральная группа функций, которые запускают ожидание действий пользователя и определяют алгоритм работы программы в зависимости от того, какое действие произвёл пользователь, с каким элементом системы и в каком состоянии в текущий момент времени находятся значимые в каждом конкретном случае элементы системы (см. рис. 1 - сущности и переходы между начальным псевдосостоянием «Начало» и переходами после сущности «Проверка условий»).
Заключение
ВОИМКСС позволяет:
• работать с содержимым редактируемой страницы «по месту»,
• создавать html-страницы;
• добавлять и удалять элементы на html-страницах;
• перемещать элементы при помощи мыши;
• изменять размер элементов при помощи мыши;
• изменять значения атрибутов и параметров стилей элементов через Object Inspector;
• работать с текстовым содержимым элементов;
• сохранять внесённые изменения в сессию и в базу данных.
Методика разработки механизма учитывает возможность расширения функционала как в ширину, за счёт добавления любого количества функций в блоках (перехвата событий, формирования представления интерфейса пользователя, редактирования объекта, работы с сервером через механизм Ajax) без их реконструкции, а также в глубину, за счёт возможности увеличения размерности массива хранения состояний возможных действий, что позволяет допустить одновременную активность двух действий одного ранга или даже одновременное выполнение двух действий над различными объектами. В результате появляется возможность оперировать ВОИМКСС неограниченным количеством активных объектов.
Литература
1. Dreamweaver CC, http://www.adobe.com/ru/products/dreamweaver.html
2. Знакомство с Microsoft Office FrontPage 2003, http://office.microsoft.com/ru-ru/frontpage-help/HA001071499.aspx?CTT=1
3. Zend Studio - The Leading PHP IDE, http://www.zend.com/products/studio/
4. Delphi for PHP 2: прежним курсом, http://ko.com.ua/delphi_for_php_2_prezhnim_kursom_37552
5. 1С-Битрикс - система управления сайтом, http://www.1c-bitrix.ru/
6. Wordpress, http://ru.wordpress.org/
7. Микляев И.А., Матричная универсальная объектно-реляционная база данных// Материалы, 1 Международная научно-практическая конференция Объектные Системы - 2010, Ростов-на-Дону, 2010,стр.34-39
8. Микляев И.А. Матричная универсальная объектно-реляционная база данных на реляционной платформе: монография/ Сев.(Арктич.) федер. Ун-т им. М.В. Ломоносова. - Архангельск: ИД САФУ, 2014. -226 с.
32
УДК 004.4, 004.65
ИНТЕГРАЦИЯ SQL-ОРИЕНТИРОВАННЫХ СУБД И NOSQL-СИСТЕМ НА УРОВНЕ
ОБЪЕКТНОГО ОТОБРАЖЕНИЯ1
Посконин Андрей Владимирович, аспирант кафедры Системного программирования факультета Вычислительной математики и кибернетики Московского государственного университета им. М. В. Ломоносова, Россия, Москва, aposk@yandex.ru
Современные приложения вынуждены работать с данными различной структуры, объема и степени важности, предъявляя к системам хранения данных достаточно жесткие (а порой и невыполнимые) требования. Отсутствие универсального решения для работы с данными привело к появлению на рынке большого числа узкоспециализированных систем, значительно отличающихся от традиционных SQL-ориентированных СУБД. Этот новый класс систем получил собирательное название «NoSQL» («Not Only SQL»), подчеркивая тем самым, что в ряде задач применение реляционных СУБД может быть не самым эффективным решением.
Стремительное развитие Интернет и Web-приложений вывело на первый план проблему масштабируемости при возрастающих нагрузках и объемах информации, которую NoSQL-системы стараются решить с использованием распределенных архитектур в противоположность классическим «односерверным» СУБД. Однако поддержка согласованности данных (и, особенно, поддержка ACID-транзакций) в условиях распределенности увеличивает не только сложность системы, но и время отклика, из-за большого числа сетевых взаимодействий. По этой причине NoSQL-системы ослабляют гарантии согласованности данных и отказываются от ACID-транзакций в пользу масштабируемости, скорости и высокой доступности данных (см., например, [1]). Системы категории NoSQL, кроме того, основаны на нереляционных моделях данных (например, ключ-значение, документная модель и т.д.), ориентированы в основном на работу с неструктурированными или слабоструктурированными данными и используют отличные от SQL языки запросов и интерфейсы доступа к данным. Стоит также упомянуть о появлении нового поколения SQL-ориентированных СУБД, изначально создаваемых для работы в распределённой среде, - так называемых NewSQL-системах. Эти СУБД поддерживают транзакционную семантику и язык SQL, но обеспечивают при этом приемлемую масштабируемость. Подробные обзоры существующих NoSQL- и NewSQL-решений можно найти, например, в [2-4].
1 news 4
t id INT
published DATETIME
О text TEXT
L )
—H
1 comments
t id INT ■^newsld INT published DATETIME <> author V ARCHAR(60) text TEXT
1
{
"Jd": Objectld("4cD2c58de5OOfie1be1C0OOO5"], "published": I SQDate["2014-04-01 T00:00:00.00QZ"), "text”:". ",
"comments": [
{
"author": "userl",
"published": ISODatef. ")r "text"
{
"author": "user2",
"published": ISODatef "text":
>
]
}
Рис. 1 - Реляционная и документная модели данных
1 Статья рекомендована к опубликованию в журнале "Информационные технологии"
33
