Содержание к диссертации
Введение
ГЛАВА 1. Обзор технологий программирования, позволяющих повысить качество сопровождения кода . 11
1.1. Принцип разделения ответственностей (Separation of Concerns) и компонентное программирование, как основа построения подхода для эффективного сопровождения кода 15
1.2. Расширяемое программирование (extensible programming) 18
1.2.1. Технология вертикального слоения А.Л. Фуксмана 19
1.2.2. Расширяемые программы М.М. Горбунова-Посадова 21
1.3. Аспектно-ориентированное программирование 24
1.3.1. Методы аспектной декомпозиции 28
1.3.2. Недостатки аспектно-ориентированного подхода 32
1.4. Виды спецификаций и способы их выработки. Роль спецификаций в построении гибкого сопровождаемого приложения 34
1.4.1. Подходы к выработке спецификаций 35
1.4.2. Роль спецификаций в построении гибкого сопровождаемого приложения 36
1.5. Выводы 38
ГЛАВА 2. Новый способ декомпозиции кода, основанный на аспектно-ориентированной парадигме 38
2.1. Фактор сосредоточенности. Рассредоточенный код и причины его появления 39
2.1.1. Рассредоточенный и сосредоточенный код 39
2.1.2. Причины появления и методы работы с рассредоточенностью кода 44
2.1.3. Классификация рассредоточенного кода 50
2.1.4. Значимость фактора рассредоточенности в программном коде 52
2.2. Предлагаемый метод аспектнои декомпозиции 54
2.2.1. Точки присоединения и их классификация 55
2.2.2. Этапы проектирования модифицируемого приложения, как основа метода построения аспектного кода 61
2.3. Фактор транзакционнностии и его роль для развития программы 72
2.4. Выводы 74
ГЛАВА 3. Применение XML спецификаций для моделирования сложно-структурированных программных объектов 75
3.1. Принципы построения спецификаций аспектов 75
3.2. Построение многоуровневых спецификаций 79
3.2.1. Цепочечный подход и его обобщение 79
3.2.2. Метод цепочек спецификаций 84
3.3. Метод аспектнои декомпозиции и его сопряжение с методом цепочек спецификаций 98
3.4. Выводы 104
ГЛАВА 4. Реализация программного комплекса «xpectengine» и оценки эффективности применения разработанного метода аспектной декомпозиции 104
4.1. Практическое применение метода автоматической генерации компонент на примере программного комплекса «XpectEngine» 105
4.2. Оценки эффективности и сложности разработанного меюда аспектной декомпозиции. Сравнение полученных оценок на различных задачах 119
4.3. Выводы 121
Заключение 121
Литература
- Расширяемое программирование (extensible programming)
- Причины появления и методы работы с рассредоточенностью кода
- Построение многоуровневых спецификаций
- Оценки эффективности и сложности разработанного меюда аспектной декомпозиции. Сравнение полученных оценок на различных задачах
Введение к работе
Развитие программного кода, связанное с процессом сопровождения программной системы, вследствие высокой конкуренции на рынке программного обеспечения, должно происходить оперативно и, при этом, не в ущерб работоспособности этой системы. Часто работа по модификации и сопровождению программы может потребовать больше времени, чем все время, потраченное на ее разработку. В силу многих факторов, на этапе проектирования системы вопросы сопровождения часто не затрагиваются, чго приводит к появлению сложного «наслоенного» кода, который со временем становится неочевидным и чрезвычайно трудным для понимания и модификаций.
В работе Дейкстры [1] был предложен метод «разделения ответе івенностей» (Separation of Concerns), согласно которому четко локализованный код гораздо предпочтительнее, чем функционал ьно-нелокализованный, так как последний сложнее для обозрения и понимания. Дейкстра заключал, что локализованный код проще поддается отладке и повторному использованию, и, следовательно, такой код удобнее поддерживать. Дейкстра указал на необходимость локализации кода, но им не были сформулированы принципы декомпозиции. Структурный и объектно-ориентированный подходы предлагают способы достижения поставленной цели, однако, далеко не всегда успешные. Несмотря на глубокие различия, они имеют общую черту — использование функциональной декомпозиции на всех этапах жизненного цикла системы. При этом многие требования, которые должны найги отражение в программном коде, не могут быть четко реализованы в терминах функциональной декомпозиции по причине того, что они относятся к функционированию всей системы в целом, а не к ее отдельным компонентам. Обычно решение этой проблемы состоит в ручном «запутывании» кода с целью повышения эффективности системы, в ущерб четкой локализации
6 кода [2]. Необходим отдельный уровень декомпозиции для четкого их обозначения и реализации.
Одна из і лавных проблем, которой в работе уделяется особое внимание — это проблема рассредоточенности кода, известная по работе А.Л. Фуксмана [3], как проблема «сосредоточенного описания рассредоточенных действий», или проблема «сквозной функциональности» в терминологии аспек і но-ориентированного подхода.
Существует несколько подходов для достижения приемлемой локализации кода. Особенно значимые успехи были получены в рамках аспекгно-ориентированного подхода, претендующего на решение проблемы рассредоточенности кода. Однако в действительноеги, аспектная ориентированность является расширением объектно-ориентированного подхода, что не позволяет перенести его идеи на императивные и декларагавные языки, а также на произвольные текстовые файлы (например, проектная документация может представлять собой текст, содержащий связи с кодом программы, а также список внутренних ссылок для быстрой навигации). Аспектная декомпозиция позволяет разбиіь программу на модули-аспекты, где каждый аспект — это функционал системы, влияющий на нее, как на целое, и пересекающий ее. Невыделенные явно аспекты тесно переплетаются с кодом программы.
Таким образом, актуально исследование в области поиска таких методов локализации кода, которые бы позволили разделить пересекающуюся логику с целью оптимизации сопровождения программного обеспечения.
В данной работе предлагается решение проблемы реализации сквозной функциональности, позволяющее сократить стоимость внесения изменений в программный код. Работа является продолжением и развитием работ А.Л. Фуксмана, а также идей о рассредоточенном коде и о вертикальном слоении программы.
Одной из наших целей является создание специальной
инструмен гальной поддержки для логического представления программы. В
основе подхода лежит возможность структурного разбиения программы на
составляющие модули.
Область исследования.
Аспектная декомпозиция кода и его сопровождение. Модульное программирование.
Предмет исследования.
Структуризация программного кода с учетом возможных и наиболее вероятных его модификаций.
Цель и задачи работы.
Целью данной диссертационной работы является разработка методов структуризации программного кода, когорые бы способствовали повышению качества сопровождения разрабатываемой системы.
Для достижения поставленной цели решаются следующие задачи: - разработка методов применения аспектно-ориентированной парадигмы, не ограниченных исключительно объектно-ориентированными языками, путем разрешения следующих задач:
о расширение области применимости точек связывания на не
объектно-ориентированные языки; о расширение области применимости аспектов на не объектно-ориентированные языки;
разработка подхода для расширения масштабов повторного использования аспектного кода;
разработка способа автоматической генерации программною кода по высокоуровневым спецификациям;
реализация метода автоматической генерации программного кода по высокоуровневым спецификациям на основе предлаїаемой архитектуры.
Научная новизна.
Предложена общая классификация точек связывания, разработан новый вид точек связывания «прямые точки связывания» и определено его место в предложенном классе;
разработан статический подход «вплетения кода»1, основанный на прямых точках связывания;
использована параметризация модуля изменений методом морфологического анализа [5] для расширения области его применимости;
разработан «метод цепочек спецификаций», где в качестве звена цепи используется спецификация, что позволило:
использовать вертикальные и горизонтальные преобразования над спецификациями;
выражать аспекты звеньями цепи;
разработан метод автоматической генерации проіраммного кода по высокоуровневым спецификациям и метод его безболезненной инсталляции;
разработан и реализован программный комплекс «XpectEngine» для преобразования высокоуровневого аспектного кода к
1 Впервые термин введен в работе [4]
9 низкоуровневому коду XML, HTML, JavaScript, ActionScript, a также к тексту документации.
Практическая ценность.
Результаты проведенных исследований были использованы при создании программного комплекса «XpectEngine» в ФГНУ НИИ «Спецвузавгоматика», который был зарегистрирован [6] и используется в настоящее время в Министерстве экономики, торговли, внешних международных внешнеэкономических связей Ростовской области, а также для поддержки сетевого портала администрации города Батайска, о чем имеются справка и акт о внедрении. Программный комплекс «XpectEngine» іакже применялся при создании веб-сайта кафедры информатики и вычислительного эксперимента РГУ.
Апробация результатов работы.
Результаты работы докладывались и обсуждались на следующих научных конференциях:
международная конференция «Технологии Microsoft в теории и практике программирования» (г. Москва., МГУ им. Ломоносова, 2004);
международная конференция «Ломоносов-2004» (г. Москва., МГУ им. Ломоносова, 2004);
XI Всероссийская научно-методическая конференция «Телематика-2004» (г. Санкт-Петербург, ИТМО, 2004);
V всероссийская научно-техническая конференция «Теоретические и прикладные вопросы современных информационных технологий» (г. Улан-Удэ, ВСГТУ, 2004);
X международная открытая научная конференция «Современные проблемы информатизации в технике и технологиях» — 3 доклада (г. Воронеж, ВГТУ, 2005);
XI международная открытая научная конференция «Современные проблемы информатизации в моделировании и программировании» — 3 доклада (г. Воронеж, ВГТУ, 2006).
Публикации.
По теме диссертационной работы опубликовано 14 печатных работ: 1 статья в издании, рекомендуемом ВАК для публикации основных научных резулыатов диссертации на соискание ученой степени доктора наук; 1 статья в электронном журнале; свидетельство об официальной реіистрации программы для ЭВМ; 11 статей в сборниках трудов и сборниках тезисов конференций.
Основные результаты, выносимые на защиту.
Предложена новая концепция построения программного кода с учетом возможных и наиболее вероятных его модификаций.
Разработан статический автоматический подход генерации и вплетения проіраммного кода, основанный на применении «прямых точек связываний» и высокоуровневых спецификаций.
Разработан метод цепочек спецификаций для реализации вертикальных и горизонтальных преобразований спецификаций аспектов.
4. Разработан программный комплекс «XpectEngine» для преобразования высокоуровневого аспектного кода к низкоуровневому результирующему коду.
Расширяемое программирование (extensible programming)
В основе множества подходов, способных улучшить качество сопровождения программы, лежи г технологический принцип расширения, согласно которому, программный код следует писать таким образом, чтобы в дальнейшем, при необходимости, его можно было легко и безболезненно модифицировать, не нарушая целостности уже написанной системы.
Расширяемость облегчает сопровождение системы и снижает расходы на ее модернизацию. Модернизация или полный переход на новую версию системы в меньшей степени осложняет работу конечных пользователей, так как изменения можно выполнить поэтапно [34].
Рассмотренное компонентное программирование и современные реализации модели СОМ в ряде случаев соответствует указанному технологическому принципу, однако нередко на практике оказывается, что выработанные компоненты весьма громоздки. Иногда удается построить так называемую обертку-расширение над отдельными компонентами, добавив или переопределив необходимые методы. Тем не менее, очень часто разработчики отказываются от уже написанных компонент, создавая новые. Таким образом, сопровождение системы все чаще сводится к полному переписыванию ее базовых составляющих.
Идея расширяемого программирования вытекает из технологического принципа расширения. Согласно Никлаусу Вирту, расширяемое программирование подразумевает, что можно добавлять модуль без необходимости вносить какие-либо изменения в существующие модули [10]. По Вирту, система должна быть гибко расширяемой, поскольку это позволит ей стать простой, эффективной и полезной. Следовательно, в нее могут быть добавлены новые модули, которые включают в себя новые процедуры на основе вызова уже существующих. Это также означает, что в новых модулях моїут быть определены новые типы данных, совместимые с существующими шпами.
Технология вертикальных слоев А.Л. Фуксмана основана на расширяющих функциях с целью сосредоточения описаний рассредоточенных действий (фрагментов кода, находящихся в разных частях программы). Расширяющие функции — это функции, изъятие которых не является катастрофическим для системы, и лишь несколько обедняет режим ее функционирования. Вначале предлагается создать предельно «обедненную» версию системы, называемую основой, к которой затем последовательно добавляются вертикальные слои, реализующие отдельные расширяющие функции [3].
Основная идея подхода — разделение программы на горизонтальные слои (фундамешальные, редко изменяемые) и вертикальные (подверженные пересмотру и модификациям). Любая модернизация является, в сущности, добавлением некоторых новых слоев. Весь аппарат, поддерживающий вертикальное слоение при создании программы, оказывается равным образом полезным и для ее модернизации.
Поняше «вертикальный слой» — это центральное понятие работы [3]. Указывается, что он обычно состоит из программных фрагментов, входящих в реализующие модели разных горизонтальных уровней. По сути, вертикальный слой является рассредоточенным действием. Его текст — это набор вставок в фоновую программу, в качесіве которой может рассматриваться основа.
Вертикальный слой сосредотачивает части системы, каждая из которых обеспечивает реализацию некоторой содержательной функции. В этом, заключает автор, состоит основное отличие от частей, выделяемых по гехнолої ическому принципу, например от процедур, представляющих повторяющиеся участки программы, не имеющие цельного содержательного значения.
Цель подхода — облегчение модернизации системы по мере ее эксплуатации, увеличение «познаваемости системы».
В работе обосновывается, что технология вертикального слоения повышает надежность создаваемых программ. Данный факт связывается с тем, что применяемый подход позволил увеличить «познаваемость сисіемьі», а значит и ее сопровождаемость.
Рабоїа А.Л. Фуксмана [3] представляет огромный интерес, поскольку в ней впервые был предложен способ декомпозиции программы с учегом ее дальнейшего развития. Важное место было уделено тому факту, что фактически само создание системы сводится к процессу непрерывной модернизации, начиная с основы [11].
Причины появления и методы работы с рассредоточенностью кода
Для исключения двусмысленности последующего изложения введем ряд определений, основываясь на терминологии рассмотренных подходов обзорной главы настоящей работы, а также на личном опыте.
Рассредоточенный код — результат структурной декомпозиции программы, при котором фрагменты кода, отвечающие некоторой функциональности, не образуют непрерывный текст.
Будем разделять рассредоточенный код на три основных подвида.
Запутанный код (codeangling) — рассредоточенный код, появляющийся в результате выбора парадигмы программирования (объективный фактор).
Спутанный код (obfuscating-code) — рассредоточенный код, появляющийся, в результате действия многих факторов, включая сложную оптимизацию кода, выбранную модульность, а также непрофессиональное проектирование и неоправданную декомпозицию. Субъективный фактор.
Переплетенный код (code-weaving) — рассредоточенный код, получаемый в результате работы генератора.
Генератор (generator) — программа, которая вырабатывает реализацию программного продукта на основе его высокоуровневой спецификации [9].
Из рассмотренного выше примера (Листинги 1-4) видно, что запутанный код, вообще говоря, не может быть распутан с точек зрения парадигм объектно-ориентированного или процедурного программирования. Данный факт, в частности обосновывается в работе [27]. Другими словами, в рамках какой бы парадигмы разработчик не находился, он неизбежно столкнется с фактором рассредоточенности. Проблема не решается на уровне существующих языковых средств, потому что предлагаемая ими декомпозиция не ставит целью налаживание логических связей между фрагментами кода, относящимися к некоторому функционалу, а предлагает методы создания и вызова отдельных модулей (методов, процедур и функций), которых не достаточно для оформления функционала, как целого. Так, в рассмотренном выше примере стандартными инструментами не удается локализовать код в виде непрерывного модуля. Также неверно, что «хорошая» организация кода способна разрешить проблему рассредоіоченности или даже свести ее к минимуму, поскольку на практике не существует способа, позволяющего предусмотреть необходимую структуризацию кода для внесения необходимых изменений на данном этапе. Например, достаточно сложно предусмотреть, что текущее тривиальное условие, может вырасти в достаточно сложную логику, требующую оформления, например, в виде метода и обращения.
Выбирая способ декомпозиции при пополнении имеющегося кода, разработчик неизбежно сталкивается с вопросом выбора модульности. Очевидно, что всегда существует несколько способов проектирования и реализации нового функционала, например, можно собирать код по вертикальным слоям, но также можем осуществлять и горизонтальную сборку. Возможна сборка в объектом стиле, но также возможна и в процедурном. Безусловно, главным рецептом облегчения внесения изменений является тщательно продуманная структура программы. Таким образом, приходим к выводу, что выбираемый программистом способ декомпозиции кода для решения задачи — это один из субъективных факторов появления рассредоточенности.
Построение многоуровневых спецификаций
Исходные тексты программ имеют определенную структуру, зависимую от выбранного языка программирования. Часто удобно и важно накладывать на эти тексты другую структуризацию, связанную с тем или иным взглядом рассмотрения этих текстов. Обычно разработчик стремится разделять код на всевозможные абстракции, подобно процедурам, модулям или компонентам. Такое деление объясняется необходимостью изолирования различного поведения, отделения интерфейса от сложностей выполнения, улучшению понимания структуры программы.
Немаловажно также, а иногда и первостепенно, собирать код в специализированные объекты приложения для их повторного использования (reuse), оценивая тем самым потраченное время и силы на разработку. К подобным объектам относятся модули, библиотеки, компоненты — абстракции, призванные облегчить, как процесс реализации программы, так и ее сопровождение.
Фактически, каждая цель рассмотрения программы, например, анализ реализации некоторой функциональности, требует выделения одних фрагментов программы и «фонового» рассмотрения других. Почти всегда при подобном делении достигается сразу несколько из преследуемых целей, что дает уверенность в правильно-выбранном пути и нередко помогает избежать спутанности кода, предоставляя возможность быстрого восстановления логики всего проекта, если, например, по какой-либо причине разработчик долгое время им не занимался.
Во время выделения в программе абстракций, и затем их оформления в виде модулей, разработчики постоянно сталкиваются со сложностями, обусловленными неоднородностью данных. Неоднородность складывается из разнотиповых переменных, таблиц, объектов некоторого класса, записей и друїих. Основная задача, возникающая в данном контексте — это задача передачи данных между отдельными модулями.
Обмен информацией возникает на различных уровнях взаимодействия. Такими уровнями могут быть отдельные программы, библиотеки, разного рода модули и другие. При рассмотрении кода с такой точки зрения обычно юворятоб исследовании возникающих или возможных потоках данных.
Множество связанных модулей взаимодействуют между собой через передачу данных, при этом данные являются входными для одного и Пусть X, Y, Z - множества данных. Будем называть модулем, действующим на множестве данных M( zX) всякое отображение f:M- N, где #(сУ). Здесь M,N — множества входных и выходных данных соответственно.
Назовем два модуля /: М(с X)- Y и g: N( z Y) - Z связанными, если VxeM 3y =N:f(x) = y и VyeN 3zeK(czZ):g(y) = z. To есть, g(f(x)) = z или x = f -»g = z, где x — входные данные, аг— выходные данные.
Рассмотрим пример. Пусть а, Ь, с, d, е, д (сМ) — набор входных данных, a fl (а), f2(b, с), f3(d, е, д) —модули. И пусть известно, что существует связь f3(fl(a), е, f 2 (b, с)). Требуется получить выходные данные от модуля f 3.
При обычном подходе решение поставленной задачи сводится к обратному ходу вычислений. На первой стадии исполняются fl(a) и f2 (b, с), затем результаты пересылаются в f3, который, получив весь необходимый набор данных, производит с ними необходимые действия. Конечно, такое решение может показаться достаточно очевидным. Действительно, вначале осуществляется процесс сбора и подготовки данных, затем их передачу тому модулю, который должен произвести над ними какие-го преобразования. Особенностью является то, что информация о существовании f 3 известна заранее, а следовательно, известна информация о структуре входных данных — типах переменных и особенностях их вызова. Но что будет, если в распоряжении окажется модифицированный модуль _f 3, зависящий от других входных данных? Ясно, что в такой ситуации, согласно обратному ходу, придется снова заранее подготавливать данные, используя необходимые модули, и затем, передать эти данные на уровень выше, но теперь это уже могут быть совсем другие модули. Таким образом, для осуществления замены модуля f3 на _f3, требуется изменение их окружения. В результате, при модификации программы она будет подвергаться значительным изменениям, которые однажды могут привести ее к неработоспособности. Следовательно, нарушится один из базовых принципов «правильной модификации» — принцип безболезненности вносимых изменений.
Для разрешения поставленной задачи на практике оказывается, что достаточно определить необходимые структуры заранее, то есть реализовать гак называемый банк данных, в который наряду с заданными входными данными будут также включаться выходные данные от исполнения существующих в системе модулей, способные доопределить неполный исходный набор. То есть, достаточно потребовать, чтобы связанные модули работали с единой структурой — структурой, в которой входные и выходные данные неотличимы.
Оценки эффективности и сложности разработанного меюда аспектной декомпозиции. Сравнение полученных оценок на различных задачах
Сложность программы зависит от многих факторов: размера программы, способа структуризации, внутренних и внешних связей между модулями. Для измерения сложностей используют так называемые «метрики», численные значения сложности, устанавливаемые по различным криіериям. Принято считать, что существуют 3 рода метрик для оценки сложности программ: - по размеру программы; - по сложности потока управления программ; - по сложности потока данных программ.
Основываясь на данных численных экспериментов разнородных мегрик, можно сделать заключение о применимости выбранного подхода и его эффективности.
Сравнение оценок по метрике Холстеда (по размеру программы) [23] для оценки усилия программиста при разработке программы на различных задачах показало от 1,3-х до 8-й кратного уменьшения показателя. Так, на «задаче о добавлении авторизации и журнализации в код методов» для объектно-ориентированной реализации коэффициент усилий (Halstead Effort) IIEF = 6258. Аспектная реализация при помощи AspectJ — HEF = 1001 [18]. Применение методов аспектной декомпозиции кода, предложенных в данной работе, позволило снизить коэффициент до HEF = 857.
Цикломатическая сложность Маккейба (Cyclomatic Complexity, СС) [23] для оценки сложности потока управления уменьшалась, в среднем, на 9-10%. На «задаче о добавлении авторизации и журнализации в код методов» для объектно-ориентированной реализации коэффициент СС = 7. На реализации предложенным методом СС = 5. Аспектная реализация при помощи AspectJ — СС = 5 [18]. Аналогичные результаты получены для метрики Джилба — метрики оценки относительной сложности программ на основе количества операторов IFHEN-ELSE в коде.
Ввиду предложенного синтаксиса описания прямых точек связывания, оценки метрики уровня комментированности или насыщенности внутреннего описания F=N/S, где N — количество комментариев, S — количество операторов исходного текста, всегда дают положительный прирост.
Таким образом, показано, что применение разработанного метода автоматической генерации кода по высокоуровневым спецификациям на различных задачах иозволяеі уменьшить сложность кода.
Предложена реализация метода автоматической генерации программного кода по высокоуровневым спецификациям на примере проіраммного комплекса «XpectEngine». Внедрение комплекса показало значительное сокращение времени внесения изменений в уже существующий код.
В четвертой главе обосновывается выбор использованных инструментальных средств для построения программного комплекса «XpectEngine». В том числе указывается значимость применения языков сценариев для построения приложений, подверженных частым изменениям.
Во второй части главы приведены оценки сложности кода, построенного с помощью Предложенной реализации в исследованных задачах.
Заключение
Целью данной диссертационной работы являлась разработка методов структуризации программного кода для повышения качества сопровождения разрабатываемой системы.
На основе обзора существующих технологий и анализа проблем необходимо было разработать ряд подходов и методов, которые могли бы позволить рассматривать программу не только с помощью абстракций, предлагаемых стандартными средствами выбранного языка, но также и на уровне специализированных объектов — аспектов, выражающих рассредоточенное поведение в коде программы.
Для достижения поставленной цели были предложены следующие решения:
1. разработана общая классификация точек связывания и новый вид точек связывания — «прямые точки связывания». Разработан статический подход «вплетения кода», основанный на прямых точках связывания;
2. использована параметризация модуля изменений методом морфологического анализа для расширения области его применимости, что позволило формировать высокоуровневые декларативные спецификации аспектов;
3. разработан «метод цепочек спецификаций», где в качестве звена цепи используется спецификация, что позволило: - использовать вертикальные и горизонтальные преобразования над спецификациями; - выражать аспекты, определяющие рассредоточенное поведение, звеньями цепи.
4. разработан метод автоматической генерации программного кода по высокоуровневым спецификациям и метод его инсталляции.
