Автоматическая генерация программных компонент по высокоуровневым спецификациям

• Автор: Кручинин, Алексей Николаевич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Ростов-на-Дону
• Количество страниц: 164 с. : ил.

СОДЕРЖАНИЕ.
ВВЕДЕНИЕ
ГЛАВА 1. ОБЗОР ТЕХНОЛОГИЙ ПРОГРАММИРОВАНИЯ, ПОЗВОЛЯЮЩИХ ПОВЫСИТЬ КАЧЕСТВО СОПРОВОЖДЕНИЯ КОДА.
1.1. Принцип разделения ответственностей i и компонентное программирование, как основа построения подхода для эффективного сопровождения кода

1.2. Расширяемое программирование xi i

1.2.1. Технология вертикального слоения А.Л. Фуксмана

1.2.2. Расширяемые программы М.М. ГорбуноваПосадова.

1.3. Аспектноориентированное программирование.

1.3.1. Методы аспектной декомпозиции.

1.3.2. Недостатки аспектноориентированного подхода

1.4. Виды спецификаций и способы их выработки. Роль спецификаций в построении гибкого сопровождаемого приложения
1.4.1. Подходы к выработке спецификаций
1.4.2. Роль спецификаций в построении гибкого сопровождаемого приложения.
1.5. Выводы
ГЛАВА 2. НОВЫЙ СПОСОБ ДЕКОМПОЗИЦИИ КОДА, ОСНОВАННЫЙ НА АСПЕКТНООРИЕНТИРОВАННОЙ ПАРАДИГМЕ
2.1. Фактор сосредоточенности. Рассредоточенный код и причины его появления
2.1.1. Рассредоточенный и сосредоточенный код
2.1.2. Причины появления и методы работы с рассредоточенностью кода. .
2.1.3. Классификация рассредоточенного кода
2.1.4. Значимость фактора рассредоточенности в программном коде
2.2. Предлагаемый метод аспектной декомпозиции.
2.2.1. Точки присоединения и их классификация
2.2.2. Этапы проектирования модифицируемого приложения, как основа метода построения аспектного кода
2.3. Фактор транзакциошиюстии и его роль для развития программы
2.4. Выводы
ГЛАВА 3. ПРИМЕНЕНИЕ X СПЕЦИФИКАЦИЙ ДЛЯ МОДЕЛИРОВАНИЯ СЛОЖНОСТРУКТУРИРОВАННЫХ ПРОГРАММНЫХ ОБЪЕКТОВ.
3.1. Принципы построения спецификаций аспектов.
3.2. Построение многоуровневых спецификаций
3.2.1. Цепочечный подход и его обобщение.
3.2.2. Метод цепочек спецификаций
3.3. Метод аспектной декомпозиции и его сопряжение с методом цепочек спецификаций.
3.4. Выводы.
ГЛАВА 4. РЕАЛИЗАЦИЯ ПРОГРАММНОГО КОМПЛЕКСА ХРЕСТЕКаЫЕ И ОЦЕНКИ ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ РАЗРАБОТАННОГО МЕТОДА АСПЕКТНОЙ ДЕКОМПОЗИЦИИ.
4.1. Практическое применение метода автоматической генерации компонент на примере программного комплекса Хрес1Епше.
4.2. Оценки эффективности и сложности разработанного меюда аспектной декомпозиции. Сравнение полученных оценок на различных задачах.
4.3. Выводы
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА


Количество времени, которое затрачивается на сопровождение и внесение изменений в готовый программный код в рамках жизненного цикла программы, по оценкам специалистов i i занимает около всего времени. Изменения программы или системы связано не только с необходимостью исправления обнаруженных ошибок, но также и при рефакторинге. Подход к улучшению структурной целостности и производительности существующих программ, называемый рефакторингом, получил развитие благодаря усилиям экспертов в области ООП. Каждый шаг рефакторинга прост. Это может быть перемещение поля из одного класса в другой, вынесение фрагмента кода из метода и превращение его в самостоятельный метод или даже перемещение кода по иерархии классов. Каждый отдельный шаг может показаться элементарным, но совокупный эффект 1зких малых изменений в состоянии радикально улучшить проект или даже предотврашть распад плохо спроектированной программы. Методы рефакторинга позволяют поэтапно модифицировать код, внося каждый раз небольшие изменения, благодаря чему снижается риск, связанный с развитием проекта 7. Для достижения нового уровня рефакторинга необходим специальный подход и набор инструментов, которые бы позволили сократить количество ошибок при декомпозиции. Поэтапные изменения предлагается оформлять в виде гак называемых слоев модулях изменений, которые описывают одну сторону или аспект разрабатываемой системы. Командная разработка vi. Подавляющее большинство проектов пишутся не одним человеком, а командой разработчиков. Программный продукт представляет собой не только совокупность фрагментов кода по функциональности, но также разделяется и по исполнению между программистами. Состыкованные фра менты кода образуют завершенный цельный продукт. Во время процесса разработки важно учитывать влияние кода, написанного разными разрабо тиками с целью нормального функционирования системы в целом. Происходит расслоение кода по принципу принадлежности кода программисту . На это накладывается необходимость нескольким разработчикам работать с общими, но разделенными фрагментами кода, что приводит к коллизиям и нередко к потере кода, особенно в ситуациях, когда слабо обтоворены принципы взаимодействия такого кода, а также его порядок написания и изменения. Таким образом, появляется не только необходимость отказаться от прямого редактирования исходных файлов, но также и требование не использовать копирования кода в новые модули с целью добавления небольших изменений. Применение аспектов в данном контексте позволило не только существенно повысить качество кода, но также увеличило и скорость разработки программного обеспечения. Нетривиальность применения существующих средств разработки. Существующие языки программирования основываю 1ся на какойлибо одной абстрактной структуре, например, процедуре, как единственным действующим ограничении, что в корне неадекватно для многих сложных систем. Суть проблемы заключается в том, что различные аспекты поведения системы имеют свою уникальную естественную форму и соответавенно поведение, которое не может быть выражено единственной абстракцией. Так, например, не совсем ясно, что является первичным в банковской системе. С одной стороны, это операции, возникающие в банковской деятельности такие как, зарегистрировать, перевести со счета на счет, открыть счет, закрыть счет. С другой стороны, на эти операции накладывается необходимость авторизации, проверки нрав и выделение привилегий клиеизу банка, причем каждый раз, во время каждой операции. Более того, банковская сисгема это всегда распределенная система, что накладываез необходимость передачи данных по сети и обязательное шифрование, что также тесно вплетено в канву операций. Перечислены лишь некоторые особенности поведения системы и ее функционирования, но уже, очевидно, что их взаимодействие весьма сложно и неоднозначно. Нет однозначною ответа, что является первичным материалом операции или безопасность. В первом случае реализация методов перевода средств будет содержать обращение к методам, ответез венным за авторизацию и безопасность. Во вгором случае, необходимо будет реализовать метод авзоризации, обращающийся к методам перевода средств.