Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Построение архитектуры ПС по ее программному коду

Данной задаче посвящен ряд работ. Одной из них, наиболее интересной и универсальной по предлагаемому подходу, является статья В. Миронова [17]. В этой работе рассматривается технология анализа программ большого размера на основе построения графов, что обеспечивает навигацию по исходным файлам с показом необходимых свойств (например, используемых классов, методов, функций и др.). Предварительно стоит рассмотреть возможные подходы и инструментальные средства анализа и формального представления текстов программ.

  • 1. Язык иМЬ, предназначенный для определения, визуализации, конструирования и документирования артефактов программных систем. Он позволяет в объектно ориентированном виде описать систему практически со всех возможных точек зрения, в том числе и разные аспекты поведения системы. Основной недостаток - неточная семантика. Язык иМЬ предназначен для графического представления системы на среднем и высоком уровнях, но малоэффективен для описания детальной логики программ нижнего уровня.
  • 2. СА8Е-технологии - программные комплексы, автоматизирующие технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем. САБЕ-технологии использовались в реинжиниринге с момента их появления. Однако по своей природе САБЕ-средства малопригодны для низкоуровневого описания структуры ПС. Кроме того, они предполагают рассмотрение ПС со стороны организации бизнес-процессов, потоков и создания оптимальной ИС для предприятия. Несмотря на высокие потенциальные возможности САБЕ-технологии, далеко не все разработчики ПС, использующие САБЕ-средства, достигают ожидаемых результатов.
  • 3. Комплекс программ построения графов Graphviz [4], разработанный специалистами лаборатории AT&T, представляет собой пакет утилит по автоматической визуализации графов, заданных в виде описания на языке dot. В пакет утилит Graphviz входит автоматический визуали-затор dot для формирования ориентированных графов на основе входного текстового описания (на специальном языке описания объектов, связей и их характеристик) в виде графического, векторного или текстового файла. Данная технология является вспомогательным средством, обеспечивающим поддержку оптимального расположения вершин графа.
  • 4. Kscope - программа для исследования и редактирования исходных текстов больших проектов на языке С9. (Сейчас Kscope не поддерживается. Прошлые релизы и репозитарий исходного кода еще доступны на SourceForge.net.) Программа позволяет построить граф-дерево вызовов, которое наглядно показывает отношения между функциями. В Kscope используется свой подход к процессу визуализации - составление и вызов запроса. Недостатками данного подхода являются малая информативность (очень сложно увидеть на графе всю программу целиком) и ограниченность синтаксисом языка С.

Рассмотрим принципы подхода к решению задачи построения архитектуры ПС по ее программному коду [17]. Одним из способов проведения анализа является формирование графов с различным уровнем отображения внутренних объектов и связей. Модель данных большой программной системы, реализованной на языках программирования C/C++, представляет собой наборы директорий, содержащих различные по использованию файлы: с исходными кодами, с описанием типов объектов и вспомогательные. Основные принципы построения архитектуры ПС:

  • • отображение графа связей файлов проекта (показывает, каким образом исходные файлы проекта подключают друг друга);
  • • отображение иерархии наследования классов;
  • • отображение диаграммы вызовов функций (диаграмма показывает, каким образом управление попадает в выбранную функцию и куда оно передается из нее; связь на диаграмме соответствует вызову функции);
  • • регулирование объема отображаемой информации путем выделения любого элемента программы с отображением только тех элементов, которые взаимодействуют с ним;
  • • для любого элемента программы необходима возможность просмотреть участки кода, в которых этот элемент используется;
  • • сохранение исходных файлов исследуемой программы в хранилище данных;
  • • возможность выделения из всей программы только необходимой функциональной части и сборка только этой части.

Основные задачи анализа:

  • • выявление описанных, но неиспользуемых элементов;
  • • изучение исходного кода, на который отсутствует документация;
  • • исследование исходного кода для дальнейшей модернизации программного продукта;
  • • исследование исходного кода для дальнейшего переноса программного продукты на другую платформу;
  • • реструктуризация исходного кода через специально созданное хранилище данных.

Для решения задач было разработано средство анализа исходных текстов. Анализ включает в себя выделение из текстов программ необходимой разработчику информации для поиска процедур и функций, для поиска имен описания типов объектов и самих объектов. На основе выделения формируются структуры различных типов - по функциям и процедурам, по объектам (их именам, их типам) с отображением адреса нахождения искомого объекта и его связей с другими объектами (например, список всех подчиненных функций одного модуля).

Основной подход при разработке средств анализа исходных текстов - создание кросс-платформенного продукта. Использованы скриптовые языки Python, Lua. Это стабильные языки, использующиеся во многих проектах в качестве базовых или для создания расширений. Для построения графического интерфейса пользователя использована библиотека wxWidgets [5], которая позволяет приложению выглядеть одинаково на всех платформах. Основной код wxWidgets вызывает элемент интерфейса платформы, вместо того чтобы повторно его реализовывать. Это предоставляет быстрый, естественно выглядящий интерфейс на каждой платформе. Для качественной визуализации используется комплекс Graphviz. Данные технологии поддерживают большое количество платформ и распространяются под свободными лицензиями.

Структура данных системы. При анализе исходного текста программа загружает объекты в виртуальное хранилище данных и позволяет отобразить различные представления: функциональную связь (рис. 7.3), связи по глобальным объектам (рис. 7.4), связь по описателям объектов (рис. 7.5).

Схема функциональных связей предоставляет информацию о наличии описания различных функций в расположенных в разных директориях файлах и о том, где именно эти функции вызываются (каждая связь на диаграмме соответствует вызову функции). На диаграмме показано, как будет выглядеть рекурсия, - замыкание функции 7 самой в себя. Каждая функция имеет адрес вида «Директория_1, Файл_1.с, Функция^». Для построения графа связей конкретной функции можно сделать соответствующий запрос.

Схема связей по глобальным объектам похожа на предыдущую, но отображает использование глобальных переменных, констант, объектов. Схема описателей объектов отображает зависимость расположенных в разных файлах описаний классов, типов, структур. Связь вида «Типі —э Тип2» обозначает, что Тип2 является одним из составляющих Типі. В классах это отношение «Потомок —> Родитель». Именно такой вид представлений позволяет получить исчерпывающую низкоуровневую информацию о рабочем проекте. При достаточно больших проектах

происходит консолидация всей необходимой для разработчика информации в одном месте.

Отображение функциональных связей

Рис. 7.3. Отображение функциональных связей

Отображение связей между объектами

Рис. 7.4. Отображение связей между объектами

Отображение связей по описателям объектов

Рис. 7.5. Отображение связей по описателям объектов

Это позволяет разработчику объективно увидеть и оценить работу программы, найти неиспользуемые объекты (например, объект_а на рис. 7.4), обнаружить рекурсии, увидеть родительские классы и их отличие от потомков.

Технологические цепочки. Программа работает следующим образом: при выборе проекта для анализа программа производит поиск исходных файлов и при обнаружении начинает загружать их в собственное хранилище данных, разбивая на простейшие объекты и сохраняя их зависимости. На втором этапе происходит работа непосредственно с хранилищем, а именно: в зависимости от целевого представления анализируются необходимые объекты данных и строятся зависимости, происходит обращение к ОгарИущ для получения графических координат элементов. Третий этап заключается в отображении на экране полученной информации.

В данной программе у программиста есть функционал сборки приложения либо части приложения. При обычном способе сборки, который используется большинством популярных ГОЕ, будут получены исполняемый файл и набор библиотек для работы программы. Библиотеки включают в себя все функции, и вычленить только часть не представляется возможным. Обычная сборка показана на рис. 7.6.

Что делать, если требуется собрать программу только с одной или двумя основными функциями? Традиционный способ - переработка исходных текстов, ручной поиск зависимостей вызовов функций и включение в итоговый продукт только выбранных функций. Система позволяет автоматизировать этот процесс. На рис. 7.7 отображен процесс сборки только одной функции (функция !).

Файловая система

Директория_1

Сь

Файл_1. с

-IS

Файл_2.с

функция_1

функция_4

функция_2

функция_5

функция_3

функция^б

Днректория_2|

N

Файл_3.с

Файл_4.с

функция_7

функция а

функция 8

функция_Ь

функция_9

функция_с

^ Компиляция и линковка

Полученные файлы

Исполняемый файл

I | Библиотека I функций 1

Библиотека функций N

Рис. 7.6. Обычная сборка

Пользователь системы, выбрав нужную компоновку (требуемые функции) и расположение файлов целевого приложения, запускает процедуру обработки. Происходит обращение к хранилищу данных, подготовка данных, создание новой иерархии директорий и выгрузка необходимых объектов (классов, функций и т.д.) в микросреду для сборки -файлов нового проекта. Файлы имеют расположение, выбранное пользователем. Далее происходят компиляция и линковка. Результатом являются исполняемый файл с требуемыми функциями и библиотека, которая содержит требуемые зависимости. Возможность выделения необходимых функций полезна при модификации приложения, при коллективной работе, при аудите исходных текстов сторонней организацией.

Дальнейшее изложение материала этого раздела следует статьям М. Ксензова. Для исследования архитектуры программных систем используется нотация структурного моделирования, принятая в инструменте KLOCwork Architect. Этот инструмент предоставляет возможность автоматического извлечения моделей из программного кода и их редактирования. Далее рассматривается эта нотация.

Модели программных систем, используемые в KLOCwork Architect (в дальнейшем- модель) [14], отдаленно напоминают модели типа «сущность - отношение» (entity-relation models). Основными единицами модели являются архитектурные блоки и отношения.

Процесс сборки одной функции

Рис. 7.7. Процесс сборки одной функции

 
<<   СОДЕРЖАНИЕ   >>