CC BY
59
• Отсутствует интерфейс СУБД.
• Система транзакций и опция отмены добавляют к размеру файла ОБД лишние килобайты. Необходимо налаживать периодическую упаковку и чистку ОБД.
• Нет специализированного языка запросов для ZODB.
• Скудная документация вообще и на русском языке в частности.
• Не любые объекты классов Python могут сохраняться в ZODB, т. к. для полноценного ее использования достаточно большой процент объектов должен быть унаследован от специального класса persistent.
Преимущества ZODB превосходят ее недостатки, поэтому она популярна среди пользователей (рис. 3). Как видим, активность сообщества пользователей ZODB стабильна с 2005 года и даже имеет тенденцию роста по приведенной 100-бальной шкале.
Литература
1. Спикльмайр С. и др. Zope. Разработка Web-приложений и управление контентом: Пер. с англ. - М.: ДМК Пресс, 2003. - 464 с.
2. Неудачин И.Г. Среда Web-публикации объектов для студентов // Объектные системы - 2011: материалы III Международной научно-практической конференции. / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - с. 62-65.
3. Неудачин И.Г. Инфраструктура программирования в открытых кодах для студентов. //Теория
и практика применения свободного программного обеспечения: сборник трудов
участников Всероссийской молодёжной конференции с элементами научной школы. -Магнитогорск: МаГУ, 2011. - с. 57-64.
4. Неудачин И.Г. Объектный дизайн Web-порталов. Объектные системы - 2011 (Зимняя сессия): материалы V Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2011. -с. 63-67.
5. ORM как антипаттерн. Шитов Н.А., Галиаскаров Э.Г., Объектные системы - 2011 (Зимняя сессия): материалы V Международной научно-практической конференции (Ростов-на-Дону, 10-12 декабря 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2011. -с. 72-76.
6. Andrew M. Kuchling. The MEMS Exchange Tools: A shortened version of the ZPUG slides,
presented at the Python10 conference, Feb. 6 2002. [Электронный ресурс]
http://www.amk.ca/talks/2002-02-06/
УДК 004.4
МОДЕЛИРОВАНИЕ СИСТЕМЫ ПЛАНИРОВАНИЯ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛИТЕЛЬНЫХ РЕСУРСОВ В ИССЛЕДОВАТЕЛЬСКИХ ЗАДАЧАХ
Жукова Светлана Александровна, к.т.н., доцент, Чайковский технологический институт (филиал) Ижевского государственного технического университета, Россия, Чайковский, otdel [email protected] Патютько Вадим Николаевич, студент, Чайковский технологический институт (филиал) Ижевского государственного технического университета, Россия, Чайковский
Введение
Важнейшим направлением повышения эффективности информационных технологий является развитие уровня автоматизации процессов комплексных поставок потребителям разнообразных сервисных процедур. Возрастает интерес к программному обеспечению, которое предоставляет удаленный доступ к ресурсам и сервисам в едином формате. Разработка такого программного обеспечения осуществляется с применением web-технологий, технологий открытых систем, среди которых особо актуальна технология «облачных вычислений» [1].
«Облачная» модель распространения и поддержки программного обеспечения предполагает использование программных приложений в режиме удаленного доступа. Суть
73
этой модели заключается в максимальном переносе бизнес-логики и данных на сервер. При реализации этой модели все данные хранятся на сервере, вычисления проводятся на сервере, взаимодействие пользователей осуществляется посредством обмена данными через сервер. При этом на долю электронного устройства пользователя (компьютер, планшет, смартфон) остается только задача обеспечения связи с сервером и отображения информации. Таким образом, достигается независимость предоставляемого функционала от конкретного устройства - на любом компьютере, планшете, смартфоне приложение может выглядеть одинаково, предоставлять одинаковый функционал и актуальные данные. При использовании облачных сервисов не требуется оборудование локальных рабочих мест мощными вычислительными ресурсами, т.к. приложения выполняются удаленно. Применение данной технологий актуально для комплексной автоматизации процессов поддержки исследовательской деятельности. Для этого разрабатывается проект «Автоматизированная система открытых виртуальных лабораторных комплексов» (далее АС ОВЛК), номер государственного контракта: 02.740.11. 0658 от 29.03.2010, целью которой является интеграция ресурсов исследовательской деятельности для обеспечения доступности и удобства их использования пользователями путем их размещения в глобальном информационном пространстве [2]. К ресурсам исследовательской деятельности относятся интеллектуальные ресурсы (модели объектов и методы их исследования, программы ЭВМ, реализующие методы, результаты экспериментов); организационные ресурсы (правила и инструкции выполнения исследования, нормативная документация, полезные ресурсы по тематикам научных исследований); вычислительные ресурсы (программно-аппаратные комплексы, необходимые для выполнения экспериментов). Совокупность ресурсов формируется в соответствии с задачей исследования и образует виртуальный лабораторный комплекс. Основные задачи системы:
• автоматизация формирования лабораторных комплексов и их представление удаленному пользователю в виде готового инструмента организации деятельности, обеспечения всей необходимой документацией;
• централизованный сбор и хранение данных о ресурсах исследовательской деятельности, обработка данных при выполнении численных экспериментов,
• организация образовательного процесса с использованием виртуальных лабораторных комплексов для проведения практических и лабораторных занятий;
• автоматизация процесса формирования документации и обмен результатами экспериментов с внешними системами;
• визуализация результатов экспериментов;
• организация коллективной работы над проектами;
• рациональное использование вычислительных ресурсов.
1. Постановка задачи
Одной из ресурсоемких задач системы является выполнение экспериментов. Решение этой задачи предполагает предоставление в общий доступ вычислительных ресурсов группе пользователей в соответствии с потребностями для выполнения экспериментов. В настоящее время предлагается ряд технологий обеспечения производительности: параллельные
технологии, GRID-системы, кластеры. Наиболее подходящей технологией для реализации этой задачи является организация распределенных вычислений, преимуществом которой является возможность наращивания производительности за счет горизонтального масштабирования, т.е. добавление вычислительных узлов в состав системы и рационального их распределения между вычислительными задачами, в нашем случае - экспериментами. Для решения данной задачи в рамках проекта разрабатывается подсистема планирования вычислительных ресурсов, которая позволяет выполнять следующие функции:
• добавление вычислительных ресурсов и их регистрацию в составе системы;
• оценка вычислительных мощностей подключаемого вычислительного ресурса;
74
• расчет требуемых вычислительных мощностей для ВЛ в зависимости от введенных начальных условий;
• планирование распределения вычислительных ресурсов между экспериментами пользователей;
• запуск эксперимента на удаленном вычислительном ресурсе.
Вместе с тем подсистема планирования эксперимента должна соответствовать
требованиям, для которых определены количественные и качественные характеристики:
• функционирование на наиболее распространенных вычислительных платформах с минимальными усилиями по настройке, Koln (чел/час);
• корректная обработка запросов пользователей численностью до нескольких сотен без потери производительности Kolq (чел/сек);
• допустимое время отклика Timeq. на запрос - не более 10 сек, на формирование отчетов - не более 10 минут, на обработку экспериментов - в режиме реального времени не более 1 часа, в режиме отложенного времени - не более 1 суток.
Таким образом, стоит задача разработки системы планирования распределенных вычислительных ресурсов для проведения экспериментов согласно требованиям пользователя.
Разработка данного класса систем является сложной, трудоемкой и дорогостоящей, т.к. ним предъявляются достаточно серьезные требования, а при реализации и эксплуатации системы используется высокотехнологическое программно-аппаратное обеспечение, к которому относятся сервера, кластеры, коммуникационное оборудование и системное и инструментальное программное обеспечение. В этой связи разработка системы осуществлялась в несколько этапов путем построения рядом моделей и изучения ее характеристик.
2. Этапы моделирования
Моделирование системы выполнялось с применением методологии объектноориентированного проектирования (ООП) [3,4].
Согласно методологии ООП моделирование программного продукта выполняется в следующие этапы. построение модели анализа, модели дизайна, модели реализации. Описание моделей выполнялось на языке UML 2.0 в среде проектирования IBM Rational Software Architect.
§влк
Ей ид номер Egj ид номер автора [ёдид номер ВЛ Ей дата создания Щ ид ВР_ВЛК
^Подключить ВР_ВЛК (
У вр_влк
ЕйиД номер ид номер ВР ей ид номер ВЛК
^Получить задание ( ) ^ Найти по ид ( )
Щ Найти по ид ВР [)
—О 1,,
VI..*
§ Заявка на эксперимент
Ей ид номер
Ей ид номер эксперимента Ей ид номер автора
Щтип ВР__________________
Sfjg Найти по ид автора ( ) fe Найти по ид ()________
4 ВР
^ид номер |наименование *ш объем памяти | загруженность |статус
| программная платформа | аппаратная платформа | местоположение |владелец
^дата подключение к АС ОВЛК время последнего обновления
^ Найти по загруженности ( ) ^ Найти по статусу ( )
^ Найти по ид ( ) ^Обновить информацию [ ) Запустить расчеты [ )
\ 1 / § Расписание
\ / 1 щ позиция заявки в расписании
Q Планировщик Eg, ид номер заявки
Ей статус
^Расчитать время обработки ( ) Ей приоритет
^Планирование ( ) „ Ед время поступления заявки
Создать ВР ВЛК [ ) 1 1 Eg; время обработки заявки
Ей ид номер ВР_ВЛК
А Найти ВР по загруженности ( ) ^Добавить в расписание [ )
^Удалить заявку из расписания ( )
^ Найти заявку по ид ()
^ Найти ВР по ид ( )
Отобразить расписание ( )
Рис. 1 - Модель анализа АИС “Учет и планирование ВР ВЛК”
75
На этапе моделирования и анализа предметной области были определены ключевые сущности, их свойства и связи между ними:
• ВЛК - объект, содержащий информацию об объекте исследования (ВЛ) и имеющий ссылку на ВР для проведения эксперимента;
• ВР_ВЛК - объект, представляющий собой вычислительный ресурс ВЛК, состоящий из группы узлов из справочника ВР;
• Расписание - объект, определяющий расписание проведения экспериментов в АС ОВЛК;
• ВР - объект, содержащий информацию о доступном вычислительном ресурсе в АС ОВЛК;
• Заявка на эксперимент - объект, содержащий требования к ВР для проведения эксперимента;
• Планировщик - объект, отвечающий за оценку требований к вычислительным ресурсам и их распределением между заявками пользователей.
Для описания модели анализа использовалась диаграмма классов, отражающая объекты
и связи между ними (рисунок 1).
На этапе моделирования структуры системы решались следующие задачи:
• определение необходимого числа уровней подчинения;
• установление между уровнями правильных взаимоотношений, что связано с задачами согласования целей элементов различных уровней и оптимальным стимулированием их работы;
• определение состава подсистем (пакетов) и связей между их компонентами.
Структура многоуровневой архитектуры АС построена в соответствии со
спецификацией проектирования распределенных объектно-ориентированных систем Java2EE, в которой система представляет собой многозвенное распределенное приложение и состоит из прикладной модели, серверной модели и модели управления транзакциями. В качестве базового архитектурного шаблона выбрана модель распределенного приложения: модель-представление-контроллер (model-view-controller, MVC) [4]. В данной модели система декомпозируется на три базовых уровня: пользовательский (View), операционный (Controller) и предметной области (Model). Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. Данная модель позволяет изолировать пользовательский интерфейс от предметной области, таким образом можно модифицировать, добавлять новые компоненты в систему (например, новые типы ВЛ), не затрагивая программные компоненты пользовательского интерфейса. Рассмотрим каждый уровень.
Уровень представления включает компоненты организации пользовательского интерфейса. Компоненты являются независимыми от выполнения основных задач приложения. Это совокупность страниц доступа к сервисам АИС, которые направляют запросы на уровень предметной области и не взаимодействуют с нижестоящим уровнем хранения данных и уровня сервисов.
Уровень операционный (controller) включает компоненты, которые распределяют задачи между компонентами системы нижнего уровня сервисов. Классы данного уровня не выполняют операции бизнес-логики, а только осуществляют координацию их выполнения.
Уровень предметной (model) области включает подсистемы, которые объединяют проектные классы, и соответствующие интерфейсы, описывающие объекты предметной области. К таким объектам относятся объекты исследовательской деятельности, электронного документооборота и администрирования вычислительных ресурсов.
В рамках спецификации Java 2EE выделен уровень DAO, в функции которого входит осуществление взаимодействия с базой данных, конвертирование данных из объектной модели в реляционную модель. На рисунке 2 представлена многоуровневая архитектура системы в соответствии с описанной моделью MVC. При моделировании декомпозиции
76
определен состав пакетов в соответствии с реализуемыми функциями системы и параметрами требований. Взаимодействие классов осуществляется посредством удаленного вызова интерфейсов, что позволяет скрыть от разработчика реализацию самого класса, а обращаться к нему посредством вызова реализуемых интерфейсов.
На этапе моделирования реализации системы построена диаграмма размещения компонентов системы по вычислительным узлам в период функционирования. При моделировании размещения программных компонентов необходимо опираться на основные нефункциональные требования к АИС: масштабируемость, расширяемость,
отказоустойчивость, высокая доступность, восстанавливаемость, производительность, гибкость.
В первую очередь необходимо, чтобы размещение компонентов по вычислительным узлам соответствовало логике работы автоматизированной системы, а также чтобы выполнялись три наиболее важных требования: возможность масштабирования (линейная и горизонтальная), возможность расширяемости и высокая производительность.
77
В начале процесса моделирования размещения программных компонентов необходимо определить их связи друг с другом, поток данных при их взаимодействии, и, как следствие, определить предпочтительную пропускную способность канала связи между вычислительными узлами, на которых будут располагаться компоненты. Также необходимо оценить возможность переноса с одного вычислительного узла на другой некоторых компонентов системы без значительных изменений в системе, путем лишь только перенаправления потоков данных. Необходимо продумать, каков будет уровень защищенности системы, как от внешних, так и от внутренних угроз безопасности.
На представленной ниже схеме (рис.3) показана диаграмма размещения комопнентов АИС на вычислительных узлах.
Рис. 3 - Размещение подсистем АИС на вычислительных узлах
Рассмотрим каждый элемент представленной схемыв отдельности.
Сервер приложений (Application Server) - ядро АС ОВЛК, программно-аппаратный комплекс, на котором размещены основные подсистемы. Сервер приложений управляет процессами выполнения необходимых расчётов для проведения исследований, вычислительными ресурсами, а также обрабатывает заявки клиента на эксперимент
Веб-портал (Web-portal Server) - сервер, на котором установлено Web-приложение, обеспечивающее взаимодействие пользователя и АС ОВЛК, принимает запросы пользователя и возвращает результаты обработки запросов, на данном сервере размещена подсистема управления контентом. На ВП размещены основные подсистемы управления контентом.
Вычислительный ресурс (CR) - предназначен для выполнения расчётов, задание на проведение которых выдает сервер приложений. На каждом подключенном к системе вычислительном узле устанавливается агент (Agent Software) задачей которого является сбор всей необходимой информации о данном вычислительном узле, оценка вычислительной мощности, получение, выполнение и выгрузка данных задания полученного с сервера приложений.
Клиент - устройство, обладающее достаточными ресурсами, возможностью взаимодействовать с АС ОВЛК посредством стандартных, открытых интерфейсов, для формирования заявки к службе на исполнение, а также на получение результата работы.
Выводы
78
Моделирование системы позволило оценить варианты архитектур, состав компонентов и схему их взаимодействия и реализовать для проведения предварительного тестирования прототипа.
Используемые технологии распределения вычислительных ресурсов позволяют предоставить доступ к мощным вычислительным ресурсам в виртуализированном виде, агрегируя имеющиеся ИКТ-ресурсы и всю вычислительную мощность в единой точке доступа к ним. Пользователь может самостоятельно обеспечивать себя вычислительными возможностями (средствами и ресурсами), такими как серверное время и сетевые хранилища, по мере необходимости запрашивая их у сервис-провайдера в одностороннем автоматическом режиме. Преимущества использование «облачных» технологий в исследовательских задачах очевидным образом достигается за счет следующих сервисов:
• Запрашиваемые сервисы доступны по сети через стандартные механизмы, поддерживающие использование гетерогенных платформ тонких и толстых клиентов (например, мобильных телефонов, ноутбуков и КПК).
• Вычислительные ресурсы провайдера услуг организованы в виде пула для обслуживания различных потребителей в модели множественной аренды с возможностью динамического назначения и переназначения различных физических и виртуальных ресурсов в соответствии с потребностями потребителей.
• Вычислительные возможности могут быть предоставлены быстро и эластично из изменяемого объема ресурсов. Для потребителя эти ресурсы часто предоставляются как доступные в неограниченном объеме и могут быть приобретены в любой момент времени в любом количестве.
• Система автоматически контролирует и оптимизирует использование ресурса, измеряя его на определенном уровне абстракции, соответствующем типу использующего его сервиса для конечного потребителя (например, объема хранения, вычислительной мощности, полосы пропускания и активных учетных записей пользователей). Использование ресурсов может подвергаться мониторингу, быть контролируемым и сопровождаться отчетностью, обеспечивая прозрачность потребления как для провайдера, так и для потребителя использованного сервиса.
Литература
1. Интернет-ресурс: «Портал информационной поддержки cloud computing » http://cloud.zapeecee.ru/home
2. Ефимов И.Н., Козлова С.Ж., Жукова С.А. Автоматизированная система интеграции открытых виртуальных лабораторных комплексов // XIII Международная научно-практическая конференция «Фундаментальные и прикладные проблемы приборостроения и информатики», Московский государственный университет приборостроения и информатики, С. 105-110.
3. Арлоу, Нейштадт. UML 2 и Унифицированный процесс: практический объектноориентированный анализ и проектирование. - Символ-Плюс, 2-е изд. - 2007. - с. 624
4. К. Ларман. Применение UML 2.0 и шаблонов проектирования. - Вильямс, 3-е изд. - 2007. -с.730
УДК 004.04
ОБЪЕКТНАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ПРАВИЛ ФОРМИРОВАНИЯ СОСТАВНЫХ ЧАСТЕЙ РЕЧИ, ИСПОЛЬЗУЕМЫХ ПРИ МОРФОЛОГИЧЕСКОМ
АНАЛИЗЕ СЛОВ РУССКОГО ЯЗЫКА
Голда Анна Анатольевна, к.ф.н., Лингвист, Переводчик, ОАО «ТАНТК им. Г.М. Бериева», Россия,
Таганрог, anva.golda@,rambler,ru
Олейник Павел Петрович, к.т.н., Системный архитектор программного обеспечения, ОАО «Астон»,
Россия, Ростов-на-Дону, [email protected]
79
