Студопедия — Реконструкция
Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Реконструкция






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

Визуализация и взаимодействие (visualization and interaction) — это механизм, позволяющий пользователю визуализировать, исследовать и управлять представлениями в интерактивном режиме. В Dali пользователь просматривает представления на графе с иерархической декомпозицией элементов и отношений, для чего существует инструмент Rigi. Пример архитектурного представления показан на рис. 10.5.

Определение и распознавание образцов (pattern definition and recognition) - это механизм архитектурной реконструкции: определения и распознавания проявления кода в архитектурных образцах. Средства реконструкции инструментария Dali, к примеру, позволяют пользователю выявлять группировки элементов и за счет этого конструировать из детальных представлений довольно абстрактные представления программной системы. Образцы, которые в Dali определяются путем сочетания средств SQL и peri, более известны нам под названием сегментов кода (code segments). С помощью запросов SQL в репозитарии Dali выявляются те элементы, которые участвуют в новой группировке; выражения peri, в свою очередь, применяются для преобразования имен и выполнения других действий по обработке результатов запросов.' Сохраненные сегменты кода пользователи могут выборочно задействовать при выполнении текущей операции, а также обращаться к ним впоследствии.

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

Предположим, что наша база данных состоит из подмножества элементов и отношений, представленного на рис. 10.6. Переменные а и b в данном примере определяются в функции f; таким образом, по отношению к f они являются локальными. Эту информацию можно представить графически — так, как это сделано на рис. 10.7.

Локальные переменные не сообщают никаких существенных сведений об архитектуре системы в целом; следовательно, в контексте архитектурной реконструкции они не слишком интересны. Таким образом, экземпляры локальных переменных можно сгруппировать в соответствующие функции. Пример кода SQL и peri, выполняющего эту задачу, показан в листинге 10.2.

В первой части этого кода обновляется визуальное отображение — вслед за именем каждой функции ставится символ «+». Затем функция группируется с определенной в ней локальной переменной. Запрос SQL отбирает из таблицы элементов нужные функции, после чего в отношении каждой строки результата исполняется выражение peri. Массив Sfields автоматически заполняется полями согласно результату запроса; в данном случае из таблицы извлечено единственное поле (tName), а это значит, что его значение в $fields[0] будет сохраняться для каждого отобранного кортежа. Выражение генерирует строки в следующей форме:

'functions <f unction > Function

Итак, элемент <function> следует сгруппировать до <function>+ с типом Function.

листинг 10.2. Группировка локальных переменных с определяющей их функцией средствами SQL и peri

I Агрегирование локальной переменной SELECT tName

FROM Elements WHERE tType='Function'; print ''$fields[0]+ $fields[0] Function\n'’;

SELECT dl.func, dlЛocal_variable FROM defines_var dl; print ''$fields[0] Sfields Cl] Function\n'';

Во второй части кода локальные переменные исключаются из визуализации. Запрос SQL идентифицирует локальные переменные во всех функциях, определенных путем отбора кортежей в таблице defines_var. Так, $fields[0] в выражении peri соответствует полю func, a $fields[l] — полю local_variable. Таким образом, выходные данные будут представлены в следующей форме:

<function>+ <variable> Function

Другими словами, в агрегат <function>+ вводятся все ее локальные переменные. Последовательность исполнения двух вышеприведенных сегментов кода не принципиальна, так как конечные результаты подачи обоих запросов подвергаются сортировке.

Графическое отображение результатов исполнения представленных сегментов кода показано на рис. 10.8.

Основным механизмом обработки извлеченной информации является обратное отображение, примерами которого, в частности, являются:

♦ идентификация типов;

♦ группировка локальных переменных в функции;

♦ группировка членов в классы;

♦ композиция элементов архитектурного уровня.

Пример запроса, идентифицирующего архитектурный элемент, показан в листинге 10.3. Выполняя идентификацию архитектурного элемента Logical_Interaction, ом попутно сообщает о том, что если именем класса является Presentation, Bsplin или Color либо если этот класс является подклассом Presentation, то он принадле жит к элементу Logical_Interaction.

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

Листинг 10.3. Запрос, направленный на идентификацию элемента LogicaIJnteraction

SELECT tSubclass

FROM has_subclass WHERE t5uperclass='Presentation’; print ''Logical_Interaction $fields[0]'1;

SELECT tName

FROM element

WHERE tName=,Presentation'

OR tName='BSpline'

OR tName='Color'; print ' ' Logical_Interaction $fields[0] ' ';

Практические рекомендации

Ниже приводится ряд практических советов по осуществлению рассматриваемого этапа.

♦ Будьте готовы к тому, что вам придется активно взаимодействовать с архитектором и провести несколько итераций по созданным архитектурным абстракциям. Этот режим особенно актуален в отсутствие у системы явной, документированной архитектуры. (См. врезку «Игра «Поймай архитектуру»».) В таких случаях имеет смысл начинать с построения архитектурных абстракций в виде гипотез, а затем, формируя представления и демонстрируя их архитектору и другим заинтересованным лицам, проверять их правомерность. Исходя из выявленных ложноотрицательных и ложноположительных результатов специалист по реконструкции принимает решения о создании новых абстракций и, следовательно, исполнении очередных сегментов кода Dali (возможно, даже новых операций по извлечению информации).

♦ Разрабатывая сегменты кода, старайтесь соблюдать краткость и не перечислять все исходные элементы. Удачный в этом отношении пример сегмента кода показан в листинге 10.3, неудачный — в листинге 10.4. В последнем составляющие архитектурный элемент исходные элементы просто перечисляются, в результате чего он становится трудным для понимания и применения (в том числе повторного).

Листинг 10.4. Пример неудачного сегмента кода, зависящего от явного перечислеиния интересующих элементов

КТ tName ь l-ROM element

WHERE tName='vanish-xforms.сс '

OR tName='PrimativeOp'

OR tName='Mappi ng'

OR tName='MappingEditor’

OR tName='InputValue'

OR tName='Point'

OR tName='VEC'

OR tName='MAT'

OR ((tName - 'Dbg$' OR tName ~ 'EventS')

AND tType^Class1); print "Dialogue Sfields[0] *';

♦ В качестве основы для построения сегментов кода можно использовать соглашения о присваивании имен, хотя в этом случае они должны последовательно соблюдаться в масштабе всей системы. Скажем, в соответствии с таким соглашением имена всех функций, данных и файлов, принадлежащих к элементу Interface, должны начинаться с префикса i_.

♦ Кроме того, основой для построения сегментов кода может быть структура каталогов, в которых хранятся файлы и функции. Исходя из этой структуры можно проводить группировку элементов.

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

ИГРА «ПОЙМАЙ АРХИТЕКТУРУ»

Перспектива восстановления «утерянной» архитектуры часто приводит в уныние. Оно и понятно — ведь команде обратной разработки предстоит с чистого листа восстановить архитектуру, которая должна, с одной стороны, адекватно отображать фактическое состояние системы, а с другой — предусматривать возможность построения умозаключений о системе, ее сопровождении, развитии и т. д.

Приступать к архитектурной реконструкции проекта имеет смысл лишь в тех случаях, когда архитектурная документация утеряна или с течением времени, в результате многочисленных пересмотров, выполненных разными специалистами, потеряла связь с реальностью. Так с чего же начать?

Когда нам впервые пришлось провести реконструкцию архитектуры нескольких систем, У нас были другие посылки. Закончив с разработкой инструментария Dali, мы должны были на чем-то его протестировать. Имея это в виду, мы отобрали несколько систем собственной Разработки и с собственноручно спроектированной архитектурой. Создавая эти системы, мы стремились к построению явной архитектуры, вследствие чего их восстановление не представляло проблемы. И тем не менее без сюрпризов не обошлось. Нарушения в архитектуре обнаружились даже в относительно небольших системах, спроектированных и кодированных нашими же руками. Это обстоятельство привело нас в некоторое недоумение: если даже небольшие системы с добротной архитектурой оказались несовершенными, то чего же ожидать от крупных коммерческих систем приличной «выдержки»? Приободрившись от достигнутых успехов, мы вознамерились взяться за одну из таких систем.

Вскоре эти «прожекты» реализовались в виде крупной комплексной системы физического моделирования. Ее разработка длилась около шести лет. Написанная на двух языках она не сопровождалась формальной архитектурной документацией; более того, ее проектировщики даже не планировали создавать таковую. При всем при этом главный архитектор намеревался, немного покопавшись, восстановить заложенную в системе архитектуру. Несмотря на то что в системе было всего 300 ООО строк кода, ничего более сложного я в жизни не видел.

Перед тем как приступить к плотному взаимодействию с архитектором, мы достали копию кодовой базы и извлекли из нее ряд весьма полезных низкоуровневых отношений (в частности, function_calls Junction и function_defines_global_variable). После этого мы заполнили со- ответствующими таблицами базу данных.

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

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

К чему я это говорю? Во-первых, первоначальные предположения о строении архитектуры нередко оказываются ошибочными. Добраться до разумной структуры с первого раза удается редко. Во-вторых, если продукт изначально создавался без осознания его четкой архитектуры, скорее всего, ее не удастся создать и впоследствии. Бесполезно пытаться «поймать архитектуру», которой нет.

-RK

Пример

Процесс реконструкции мы проиллюстрируем типичным набором сегментов кода, составленных инструментарием Dali при восстановлении архитектуры UCMEdit - системы формирования и редактирования use case карт по Буру Мы покажем, за счет чего специалисту проводившему реконструкцию, удалось на основе необработанных данных, относящихся к нескольким извлеченным представлениям, составить простую и в то же время четкую картину программной архитектуры.







Дата добавления: 2015-04-16; просмотров: 627. Нарушение авторских прав; Мы поможем в написании вашей работы!



Расчетные и графические задания Равновесный объем - это объем, определяемый равенством спроса и предложения...

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

Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями...

Композиция из абстрактных геометрических фигур Данная композиция состоит из линий, штриховки, абстрактных геометрических форм...

Реформы П.А.Столыпина Сегодня уже никто не сомневается в том, что экономическая политика П...

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

Особенности массовой коммуникации Развитие средств связи и информации привело к возникновению явления массовой коммуникации...

Основные разделы работы участкового врача-педиатра Ведущей фигурой в организации внебольничной помощи детям является участковый врач-педиатр детской городской поликлиники...

Ученые, внесшие большой вклад в развитие науки биологии Краткая история развития биологии. Чарльз Дарвин (1809 -1882)- основной труд « О происхождении видов путем естественного отбора или Сохранение благоприятствующих пород в борьбе за жизнь»...

Этапы трансляции и их характеристика Трансляция (от лат. translatio — перевод) — процесс синтеза белка из аминокислот на матрице информационной (матричной) РНК (иРНК...

Studopedia.info - Студопедия - 2014-2024 год . (0.015 сек.) русская версия | украинская версия