Применение аспектно-ориентированного подхода к созданию ортогональных долговременных объектных систем в архитектуре с веб-клиентом

• Автор: Зудин, Андрей Борисович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2010
• Место защиты: Москва
• Количество страниц: 137 с. : ил.

СОДЕРЖАНИЕ
ВВЕДЕНИЕ

1. ОБЪЕКТНЫЕ ОРТОГОНАЛЬНЫЕ СИСТЕМЫ ДОЛГОВРЕМЕННОГО ПРОГРАММИРОВАНИЯ

1.1 Системы долговременного программирования

1.2 Основные понятия и свойства ООСДП

1.2.1 Персистентность Долговрсменность.

1.2.2 Принципы ортогонального долговременного программирования

1.2.3 Объектные ортогональные долговременные системы.

1.3 Обзор проблемы и выбор путей решения.

1.3.1 Интеграция системы типов и модел и данных

1.3.2 Механизмы связывания.

1.3.3 Параллельный доступ
2. ОБЩИЕ ПРИНЦИПЫ ПОСТРОЕНИЯ РУЕВ.
2.1. Аспектноориентированное программирование
2.2. Подходы к реализации распределенных он ьектных ортогональных
долговременных систем
2.3. Выбор модели вычислений
2.3.1. Логическое представление системы.
2.3.2. Техническая реализация.
2.3.3. Работа с распределенными данными.
2.4. Метаобъекты в рУ1В.
2.4.1. Поддержка параллельных вычислений различными клиентами
2.4.2. Синхронизация доступа в рамках одного клиента
2.4.3. Управление кэш памятью объектов
3. МАТЕМАТИЧЕСКИЕ МОДЕЛИ ИСПОЛНЕНИЯ ЗАПРОСОВ В СИСТЕМАХ ДОЛГОВРЕМЕННОГО ХРАНЕНИЯ
3.1 Описание системы
3.1.1. Простая дисциплина обслуживания
3.1.2. Дисциплины обслуживания с параллельной обработкой
3.2. Дисциплина исполнения в системе с общим разделяемым ресурсом.
3.2.1. Описание системы.
3.2.2. Стохастическая модель системы
3.2.3.Вычисление показателей эффективности работы системы.
3.2.4. Пример составления СУР.
3.3. Имитационная модель.
3.3.1. Реализация имитационной модели. Результаты расчетов
Выводы.
4. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ПРЕДЛАГАЕМЫХ РЕШЕНИЙ
4.1. Архитектура ООСДП руев.
4.2. Описание метаобъвкпклт протокола
4.3. Описание стандартных метаобъектов руев.
4.3.1. Назначение метаобъекта экземпляру класса.
4.4. Реализация транзакционного подхода обеспечения параллельного доступа в
СИСТЕМЕ РУЕВ
4.5. Менеджер обьектов.
4.6. Менеджер классов
4.7. Менеджер транзакций.
ЗАКЛЮЧЕНИЕ. ОБЩИЕ ВЫВОДЫ.
СПИСОК ЛИТЕРАТУРЫ


Результаты, полученные при выполнении диссертационной работы использовались при создании специализированного программного обеспечения, при создании компонентов системы долговременного программирования в . Основные результаты диссертации докладывались и обсуждались на отечественных и зарубежных научно-технических конференциях: Международная конференция «Ломоносов-», (Москва, ), Научная конференция «Ломоносовские Чтения», Секция Вычислительной Математики и Кибернетики, (Москва, НИВЦ, ), ХЬУ1 Всероссийская конференция по проблемам математики, информатики, физики и химии. Современные информационные компьютерные технологии -тс1Т - , (Беларусь, Гродно, ). Результаты диссертации отражены в 9 опубликованных печатных работах. Общая архитектура долговременных систем была предложена во множестве работ, в частности []. В данной работе предлагаются основные элементы архитектуры и принципы проектирования и построения ортогональных клиент-серверных долговременных систем с тонким клиентом. Главной задачей долговременного программирования является создание программных средств, которые оперируют долговечными, конкурентно доступными и потенциально большими объемами информации. В дальнейшем, такие программные средства будем называть < долговременными или долговечными (ДПС). А именно, способности приложения пережить свои отдельные компоненты, а иногда даже технологии, с помощью которых они создавались. Очень часто не удается достигнуть этих целей, гак как оказывается, что затраты на поддержку и адаптацию ДПС велики. В настоящее время, технологии, которые лежат в основе ДПС (обычно называемые Системами Поддержки - Support Systems), основываются на различных механизмах и архитектурах для осуществления поддержки времени выполнения и эффективной реализации []. Среди таких “систем поддержки” принято выделять операционные системы, системы передачи данных (обычно поставляемые с операционными системами, но проектируемые отдельно), системы управления базами данных, системы пользовательского интерфейса, командные языки, редакторы, файловые системы, компиляторы, интерпретаторы, компоновщики, отладчики, языки запросов, менеджеры транзакций, менеджеры управления одновременным доступом и вычислительные архитектуры. Программистам приходится сталкиваться с различиями в именовании, типах, схемах привязки в каждой из подсистем. Вероятно, самым сложным для разработчиков является работа с различными схемами восстановления, одновременного доступа и поддержки транзакций, применяемые в различных системах поддержки. Бессвязность и сложность использования всех выше перечисленных различных приложений и механизмов конструирования систем увеличивают интеллектуальную и техническую стоимость создания даже простейших ДПС. Сложность отвлекает разработчиков от главной цели, заставляя конце! С другой стороны, различия механизмов увеличивают и техническую стоимость системы. Программный код, избыточное дублирование алгоритмов в каждой из подсистем и соревновательный доступ к общим ресурсам приводят к увеличению накладных расходов. На рисунке 1. В периоды пиковой нагрузки мы ожидаем наибольшей отдачи от ДПС. К сожалению именно в это время сбои наиболее вероятны в силу сложных внутренних связей. Разработчики I_. Рис. На схеме сплошными линиями показаны пути передачи, преобразования и отображения данных; пунктирные линии показывают какие компоненты системы, люди (пользователи и разработчики) должны понимать и иметь ввиду. Индивидуальные несоответствия между подсистемами доставляют инженерам программного обеспечения достаточно проблем. Но такие проблемы возникают для каждой пары подсистем, поэтому общая сложность системы растет мультипликативно. Эти разногласия мотивируют дизайнеров ортогональных долговременных объектных систем проектировать долговременные и масштабируемые вычислительные модели без этих сложностей. Становится понятным, что большинство таких сложностей являются волей случая, а вовсе не необходимостью. Разные подсистемы были построены в разнос время, когда инженерные приоритеты были различны.