10.7. Заключение

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

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

10.8. Дополнительная литература

В настоящее время существует несколько инструментариев реконструкции. В Институте программной инженерии (Software Engineering Institute, SEI) разработан инструментарий Dali [Kazman 99а]. Также следует упомянуть продукт разработки Sneed [Sneed 98], фабрики программного обновления, созданные Вероефом (Chris Verhoef) и его коллегами [Brand 97], а также инструментальный набор воссоздания архитектуры от Philips Research [Krikhaar 99].

Обзор стандартной формы Rigi содержится в издании [Muller 93]. Инструмент Rigi описывается в работе [Wong 94].

В труде [Bowman 99] изложен метод извлечения архитектурной документации из кода реализованной системы, сильно напоминающий Dali. В частности, там приводится пример реконструкции архитектуры системы Linux, в ходе которой путем анализа исходного кода программой cfx (это инструмент быстрого извлечения кода С) была получена символьная информация, на основе которой впоследствии провели генерацию набора отношений между символами. Затем последовала ручная древовидная декомпозиция системы Linux на подсистемы и назначение им исходных файлов. Далее при помощи утилиты обработки существенных фактов были установлены отношения между идентифицированными подсистемами, а посредством инструмента визуализации Isedit проведена вирилизация извлеченной структуры системы. Уточнить результирующую структуру удалось путем перемещения исходных файлов из одной подсистемы в другую.

Харрнс (Harris) и ряд его коллег предлагают совместить в рамках каркаса архитектурной реконструкции восходящий и нисходящий подходы [Harris 95]. Каркас этот включает три части: механизм отображения архитектуры, машину распознавания исходного кода вместе со вспомогательной библиотекой запросов на распознавание, а также механизм «панорамного» обзора программы. При восходящем анализе панорамное представление позволяет отображать файловую структуру и исходные элементы системы, а также реорганизовывать информацию в рамках более содержательных кластеров. В нисходящем анализе для выявления тех элементов, которые планируется обнаружить в программной системе, используются отдельные архитектурные образцы. Запросы на распознавание помогают проводить проверку на предмет существования ожидаемых элементов.

В работе [Guo 99] приводится обзор полуавтоматического метода восстановления архитектуры под названием ARM, подходящего, правда, только для тех систем, которые проектировались и разрабатывались с помощью образцов. Состоит он из четырех основных этапов: 1) разработка конкретного плана распознавания конкретных образцов; 2) извлечение исходной модели; 3) обнаружение и оценка экземпляров образцов; 4) реконструкция и анализ архитектуры. Параллельно с описанием метода ARM в издании приводятся конкретные примеры его применения в целях реконструкции систем и проверки их соответствия документированным вариантам архитектуры.