Диссертация (1150733), страница 15

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 15)

Анализ целей и задач реинжиниринга.На данном шаге необходимо проанализировать цели и задачи реинжиниринга конкретной информационной системы. От этого напрямую зависитвыбор средств и инструментов анализа встроенного кода. Ниже перечислены основные классы задач реинжиниринга информационных систем, затрагивающих динамически формируемый код, которые можно выделитьна данном этапе.– Задача оценки качества кода и его сложности, которая часто сводитсяк расчёту различных формальных метрик кода [59, 60]. Здесь необходимо определить, требуется ли построение структурного представления кода для вычисления требуемых метрик с необходимой точностью.– Анализ надёжности системы, поиск различного рода уязвимостей иошибок [90,91].

При этом требуется изучение типов ошибок, которыепредполагается обнаруживать: обнаружение некоторых типов оши-81бок требуют построения структурного представления кода (семантические ошибки), в то время, как в других случаях это не требуется(лексические, синтаксические ошибки).– Извлечение или восстановлении утраченных знаний о системе [4, 90].В зависимости от деталей этой задачи может потребоваться динамический анализ или структурное представление встроенного кода.– Трансформация исходной системы: рефакторинг, перенос на новыепрограммно-аппаратные системы [4, 39, 90, 92].

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

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

Более того,82в процессе разработки необходимость переключаться между несколькимидиалектами так же может вызвать трудности.Таким образом, один из основных вопросов, на которые необходимо ответить при анализе целей: планируется ли активное изменение системыпосле её реинжиниринга, если последний включает трансформации.2.

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

Необходимо оценить следующие характеристики кода информационной системы.– Количество точек интереса — тех точек, где сформированное строковое выражение передаётся на обработку соответствующей компоненте. Это позволит оценить интенсивность использования встроенногокода. Как правило, за выполнение выражений на встроенном языкеотвечают характерные языковые конструкции, например EXECUTE вязыке T-SQL. Следовательно, необходимо оценить количество такихконструкций. Для грубой оценки можно использовать простой текстовый поиск. Он может оказаться полезным, так как если он свидетельствует о полном отсутствии соответствующих конструкций, тодальнейший анализ можно не проводить. Для более точной оценкинеобходимо использовать структурное представление кода, чтобы, например, не учитывать код, находящийся в комментариях.

Получитьструктурное представление и доступ к нему можно с помощью библиотек синтаксического анализа для соответствующего языка.– Сложность формирования строковых выражений. Прежде всего необходимо определить наличие динамически формируемого кода и оценить сложность его формирования, так как в случае использованиятолько константных строковых литералов специальных инструментовдля анализа встроенного кода не требуется.83Для данной оценки можно использовать алгоритм протягивания констант [11]. Однако потребуется его модификация. Необходимо, чтобыотдельно обрабатывались выражения, отвечающие за формированиекода, и собиралась следующая информация о процессе формирования кода как для каждой точки выполнения, так и для всей системы вцелом.– Количество конкатенаций.– Количество операторов ветвления: if-then-else, switсhcase и т.д.– Количество строковых функций: replace, substring и т.д.– Количество циклов, как “явных” (while, for), так и организованных с помощью рекурсии.– Количество переменных, значения которых нельзя полностью вычислить статически (например, значения из пользовательскоговвода).– Факт формирования кода в “телах” более чем одного метода/процедуры.

Для получения данной информации в используемом инструменте необходима поддержка межпроцедурного анализа [11, 93, 93].3. Возможности доступа к исходной системе в реальных условиях можетдать большое количество полезной информации (например, сведения обинтенсивности выполнения встроенного кода), которую трудно или даженевозможно получить другими способами, так как даже тесты часто невоспроизводят реальные сценарии функционирования системы. Однако такой доступ часто оказывается затруднённым, что вызывается, с одной стороны, вопросами безопасности, с другой стороны, отсутствием возможности гарантировать, что изменения, необходимые для получения требуемойинформации (например, ведение дополнительного журнала), не отразятсяна работоспособности системы.– Необходимо определить, есть ли доступ к системе, работающей в реальных условиях, и какая именно информация доступна: чтение опре-84делённых журнальных файлов, перехват сообщений на каком-либоуровне, доступ к базе данных системы.– Необходимо определить виды доступных модификаций, а также информацию, которая не является закрытой и может быть передана разработчикам.

Это влияет на то, какие задачи можно решать при помощи динамического анализа.– Необходимо определить возможность запуска модифицированной системы в реальных условиях. Если это возможно, то важно убедиться,что будет также возможно получить доступ к собранной информации. Это позволит, например, собрать информацию о том, с какимиобъектами программы работают с использованием динамически формируемых запросов при выполнении конкретных сценариев.4. Роль динамически формируемого кода в системе.

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

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

Тот факт, что данная функциональность не является основнойдля системы, может позволить обращать меньше внимания, например,на производительность результатов трансформации. Это даёт большевозможностей для использования динамического подхода, так как накладные расходы на дополнительные вычисления во время работы системы не окажут существенного воздействия на производительностьеё основных функций.5. Анализ требований к производительности и потреблению ресурсов.Необходимо определить, на сколько допустимы дополнительные накладные расходы на обработку встроенного кода. Ответ на данный вопрос важен при выборе между статическим и динамическим подходом к трансляции динамически формируемого кода. Выполнение динамически формируемых SQL-запросов само по себе требует дополнительных ресурсов.

Если на предыдущих шагах было выяснено, что динамически формируемыйкод активно используется в критическом по производительности фрагменте системы, а вычислительные ресурсы ограничены, то применение динамического подхода неприемлемо. Это связано с тем, что дополнительные вычисления для обработки кода существенно ухудшат быстродействиекритических фрагментов системы.6. Анализ особенностей конкретного внешнего и встроенного языков.Многие задачи требуют комплексной обработки внешнего и встроенного кода. Например, при статическом поиске ошибок, включающем ошибкииспользования типов переменных, необходимо проводить анализ, проверяющий, что тип переменной во внешнем коде соответствует типу, которыйвозвращается запросом.

Характеристики

Список файлов диссертации