Файл: Инфрам.pdf

397 по использованию файлы: с исходными кодами, с описанием типов объ- ектов и вспомогательные. Основные принципы построения архитектуры
ПС:
Отображение графа связей файлов проекта. Показывает, каким обра- зом исходные файлы проекта подключают друг друга;
Отображение иерархии наследования классов;
Отображение диаграммы вызовов функций. Диаграмма показывает, каким образом управление попадает в выбранную функцию, и куда оно передается из нее. Связь на диаграмме соответствует вызову функции;
Регулирование объема отображаемой информации путем выделения любого элемента программы с отображением только тех элементов, которые взаимодействуют с ним;
Для любого элемента программы возможность просмотреть участки кода, в которых этот элемент используется;
Сохранение исходных файлов исследуемой программы в хранилище данных;
Возможность выделения из всей программы только необходимой функциональной части и сборка только этой части.
Основные задачи анализа: выявление описанных, но неиспользуемых элементов; изучение исходного кода, на который отсутствует документация; исследование исходного кода для дальнейшей модернизации про- граммного продукта; исследование исходного кода для дальнейшего переноса программ- ного продукты на другую платформу; реструктуризация исходного когда через специально созданное хра- нилище данных.
Для решения задач было разработано средство анализа исходных текстов. Анализ включает в себя выделение из текстов программ необ- ходимой разработчику информации: для поиска процедур и функций, для поиска имен описания типов объектов и самих объектов. На основе выделения формируются структуры различных типов – по функциям и процедурам, по объектам (их именам, их типам) с отображением адреса нахождения искомого объекта и связей его с другими объектами (на- пример, список всех подчиненных функций одного модуля).
Основной подход при разработке средств анализа исходных текстов
– создание кросс платформенного продукта. Использованы скриптовые языки Python, Lua. Это стабильные языки, использующиеся во многих проектах в качестве базовых или создания расширений. Для построения графического интерфейса пользователя использована библиотека wxWidgets [5], которая позволяет выглядеть приложению одинаково на всех платформах. Основной код wxWidgets вызывает элемент интер- фейса платформы, вместо того, чтобы повторно его реализовывать. Это предоставляет быстрый, естественно выглядящий интерфейс на каждой платформе. Для качественной визуализации используется комплекс

398
Graphviz. Данные технологии поддерживают большое количество плат- форм и распространяются под свободными лицензиями.
Структура данных системы. При анализе исходного текста, про- грамма загружает объекты в виртуальное хранилище данных и позволя- ет отобразить различные представления: функциональную связь (рис.
8.1), связи по глобальным объектам (рис. 8.2), связь по описателям объ- ектов (рис. 8.3).
Рис. 8.1. Отображение функциональных связей
Рис. 8.2. Отображение связей между объектами

399
Рис. 8.3. Отображение связей по описателям объектов
Схема функциональных связей предоставляет информацию о нали- чии описания различных функций в расположенных в разных директо- риях файлах и где именно эти функции вызываются (каждая связь на диаграмме соответствует вызову функции). На диаграмме показано как будет выглядеть рекурсия – замыкание функции 7 самой в себя. Каждая функция имеет адрес вида «Директория_1, Файл_1.c, Функция_1». Для построения графа связей конкретной функции можно сделать соответ- ствующий запрос.
Схема связей по глобальным объектам похожа на предыдущую, но отображает использование глобальных переменных, констант, объектов.
Схема описателей объектов отображает зависимость расположенных в разных файлах описаний классов, типов, структур. Связь вида «Тип1 ->
Тип2» обозначает, что Тип2 является одним из составляющих Тип1. В классах это отношение «Потомок -> Родитель». Именно такой вид пред- ставлений позволяет получить исчерпывающую низкоуровневую ин- формацию о рабочем проекте. При достаточно больших проектах про- исходит консолидация всей необходимой для разработчика информации в одном месте.
Это позволяет разработчику объективно увидеть и оценить работу программы, найти неиспользуемые объекты (например, объект_а на рис.
2), обнаружить рекурсии, увидеть родительские классы и их отличие от потомков.
Технологические цепочки. Технологические цепочки. Программа работает следующим образом: при выборе проекта для анализа, про- грамма производит поиск исходных файлов и при обнаружении начина- ет загружать их в собственное хранилище данных, разбивая на про-

400 стейшие объекты и сохраняя их зависимости. На втором этапе происхо- дит работа непосредственно с хранилищем, а именно: в зависимости от целевого представления анализируются необходимые объекты данных и строятся зависимости, происходит обращение к Graphviz для получения графических координат элементов. Третий этап заключается в отобра- жении на экране полученной информации.
В данной программе у программиста есть функционал сборки при- ложения, либо части приложения. При обычном способе сборки, кото- рый используется большинством популярных IDE, будет получен ис- полняемый файл и набор библиотек для работы программы. Библиотеки включают в себя все функции, и вычленить только часть не представля- ется возможным. Обычная сборка показана на рис. 8.4.
Рис. 8.4. Обычная сборка
Что делать если требуется собрать программу только с одной или двумя основными функциями? Традиционный способ – переработка исходных текстов, ручной поиск зависимостей вызовов функций и включение в итоговый продукт только выбранных функций. Система позволяет автоматизировать этот процесс. На рис. 8.5 отображен про- цесс сборки только одной функции (функция_1).
Пользователь системы, выбрав нужную компоновку (требуемые функции) и расположение файлов целевого приложения, запускает про- цедуру обработки. Происходит обращение к хранилищу данных, подго- товка данных, создание новой иерархии директорий и выгрузка необхо- димых объектов (классы, функции и т.д.) в микросреду для сборки – файлы нового проекта. Файлы имеют расположение, выбранное пользо- вателем. Далее происходит компиляция и линковка. Результатом явля-

401 ется исполняемый файл с требуемыми функциями и библиотека, кото- рая содержит требуемые зависимости. Возможность выделения необхо- димых функций полезна при модификации приложения, при коллектив- ной работе, при аудите исходных текстов сторонней организацией.
Рис. 5. Процесс сборки одной функции
8.6.3. Рефакторинг архитектуры многослойной иерархической ПС
Дальнейшее изложение материала этого раздела следует статьям М.
Ксензова. Для исследования архитектуры программных систем исполь- зуется нотация структурного моделирования, принятая в инструменте
KLOCwork Architect. Этот инструмент предоставляет возможность ав- томатического извлечения моделей из программного кода и редактиро- вания их. Далее рассматривается эта нотация.

402
Модели программных систем, используемые в KLOCwork Architect
(в дальнейшем модель) [14], отдаленно напоминают модели типа сущ- ность-отношение (Entity-Relation models). Основными единицами моде- ли являются архитектурные блоки и отношения.
Архитектурный блок (Architecture Block). Архитектурные блоки – это основные элементы, составляющие модель. Архитектурные блоки отображают структурные элементы программной системы вне зависи- мости от того уровня абстракции, на котором идет моделирование. Ар- хитектурные блоки обладают, по меньшей мере, двумя основными ат- рибутами: имя и тип. Имена архитектурных блоков предопределяются именами тех структурных элементов системы, которые они представ- ляют в модели. Типы архитектурных блоков существенно зависят от уровня абстракции, на котором проходит моделирование, и конкретной задачи, в рамках которой проводится исследование архитектуры.
При моделировании взаимодействия клиент-сервер – основной ис- пользуемый тип архитектурных блоков – “подсистема”. При модели- ровании систем, построенных в рамках компонентных технологий, – основной используемый тип – “компоненты”. При моделировании сис- темы сборки ПО – основные используемые типы - “папки” и “файлы”.
При объектно-ориентированном анализе – основной используемый тип -
“класс”.
Отношение (Relation). В модели KLOCwork Architect под отношени- ем понимается некоторая односторонняя связь между парой архитек- турных блоков. Между любой парой блоков в модели может быть про- извольное количество разнонаправленных отношений, при этом их ти- пы так же могут различаться. Так же, как и архитектурные блоки, отно- шения могут быть различных типов. В качестве примера можно привес- ти следующие типы отношений: инстанциация: A инстанциирует B (блок A – функция, блок B – класс); наследование: A наследует B (блоки A и B – классы); чтение данных: A читает данные из B (блок A – функция, блок B – класс, атрибут класса или функция); обращение: A вызывает B (блоки A и B – функции);
A использует B: (блок A – класс или функция, блок B – класс или атрибут класса).
Модели обладают следующими свойствами:
1) иерархичность – каждый архитектурный блок может содержать другие архитектурные блоки, при этом связи между архитектурными блоками суммируются. Например, если в модели есть блок A, который содержит блок А1, и блок В, который содержит В1и В2, и между блока- ми А1 и В1 есть связь, а также между блоками А1 и В2 есть связь, то считается что между А и В есть две связи, поскольку они содержат два множества блоков, и количество связей между блоками из различных множеств равно двум;
2) точность – для каждого элемента модели можно указать «стоящий за ним» в моделируемой системе набор файлов и строк кода. Точность

403 модели обеспечивается способностью инструмента KLOCwork Architect автоматически извлекать их из программного кода.
Над моделями в KLOCwork Architect определены операции редакти- рования: добавление блока, в модель допустимо добавлять новые блоки; удаление блока, из модели допустимо удалить произвольный блок; перенос блока, из модели допустимо вырезать блок и перенести его внутрь другого блока; переименование блока, в модели допустимо переименовывать блоки; объединение блоков в группу, модель позволяет объединять блоки в группы. При этом создается новый блок, и группируемые элементы переносятся внутрь него.
Важным свойством этих операций является то, что они сохраняют основные свойства модели – т. е. ее иерархичность и точность.
Инструмент KLOCwork Architect способен автоматически извлекать из программного кода базовые структурные модели, отражающие физи- ческую структуру исследуемой программной системы. В состав таких моделей входят: архитектурные блоки, представляющие папки, в которых находятся файлы с исходным кодом системы; архитектурные блоки, представляющие собственно файлы. Такие архитектурные блоки находятся внутри соответствующих блоков, которые представляют папки, содержащие эти файлы; архитектурные блоки классов, переменных, функций, находящихся внутри соответствующих блоков файлов.
В [14, 15] отмечается специфическая черта рефакторинга архитекту- ры: для достижения промежуточных целей, возникающих в ходе архи- тектурного рефакторинга, как правило, приходится выполнять более одного шага. Эти шаги относятся к различным фазам решения постав- ленных архитектурных задач. Можно условно выделить следующие фазы архитектурного рефакторинга: фаза "раскопки" архитектуры, фаза трансформации архитектуры, фаза семантического анализа подсистем и фаза проецирования изменений модели на программный код.
"Раскопка" архитектуры характеризуется тем, что соответствующие действия, применяемые к модели, не ориентированы на последующее проецирование на программный код. Они нужны только для понимания и структуризации модели.
Для шагов, относящихся к трансформации архитектуры, в отличие от шагов фазы раскопки, типично последующее проецирование их на реальный код программной системы. Шаги этой фазы четко связаны с реальной модификацией кода системы и, в конечном счете, ориентиро- ваны на его улучшение. Следует также отметить, что часть методов ре- факторинга архитектуры не может быть строго отнесена к одной из на- званных категорий (раскопка и трансформация). На практике это озна- чает, что решение о проецировании этих шагов на код принимает разра- ботчик, руководствуясь поставленной задачей.

404
Как правило, между шагами описанных выше фаз архитектурного рефакторинга предпринимаются шаги, которые можно отнести к фазе семантического анализа подсистем: по ходу трансформаций часто вста- ет задача выявления смысловой нагрузки подсистем. Для решения по- добных задач, даже в первом приближении, зачастую приходится ис- следовать реальный программный код (здесь опять-таки помогает точ- ность модели), анализировать сигнатуры функций и комментарии, а при отсутствии последних и сам код функций. Задача специалиста, вовле- ченного в процесс архитектурного рефакторинга, – по возможности ми- нимизировать объем семантического анализа (например, путем удале- ния вспомогательных блоков) и сделать его последовательным и на- правленным.
Результат последнего шага – редактирование модели должен быть спроецирован на реальный программный код системы. Действительно, при проецировании удаления блоков из модели необходимо определить множество строк и файлов, которое соответствует удаленному блоку в программном коде. После этого необходимо удалить из программного проекта выявленные строки и файлы. При проецировании на код пере- носа блока в модели переносятся соответствующие строки и файлы в исходном коде программной системы и т.д. Производимые таким обра- зом трансформации можно рассматривать как архитектур- но-управляемый рефакторинг программного кода.
8.6.4. Слои в архитектуре ПС. Паттерн выделения слоев
Концепция слоев – одна из общеупотребительных моделей, исполь- зуемых разработчиками программного обеспечения для разделения сложных систем на более простые части (см. глав 2 и 6). В архитектурах компьютерных систем, например, различают слои кода на языке про- граммирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В гл. 2 отмечалось, что если система разбита на ряд слоев, то слой n – это набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.
Слой n+1 использует слой n, следовательно, абстракция понятий слоя n+1, по меньшей мере, не ниже чем у слоя n, а в идеале – если ар- хитектура системы эффективна, его уровень абстракции должен быть выше. Соответственно, слой n скрывает (инкапсулирует) логику работы с понятиями определенными на этом слое, позволяя, таким образом, слою n+1 реализовать работу с более сложными понятиями, организо- вать более сложную логику, используя выразительные средства ниже- лежащего слоя. Можно выбирать альтернативную реализацию базовых слоев – компоненты верхнего слоя способны работать без каких-либо изменений в нижележащих слоях, при условии сохранения интерфей- сов. Зависимость между слоями, то есть, фактически, интерфейсы, пре- доставляемые нижними слоями верхним, можно свести к минимуму.