Преобразование исходного кода программ
Самый простой способ реинжениринга программ — это автоматический перевод исходного кода с одного языка программирования на другой более довременный. При этом структура и организация программ остаются неизменными. Программа может переводиться как на обновленную версию исходного языка (например, с языка COBOL-74 на язык COBOL- 85), так и на другой “не родственный” язык (например, с языка FORTRAN на С).
Причины перевода на другой язык могут быть следующие.
Обновление платформы аппаратных средств. В организации может быть принято решение по изменению аппаратной платформы. Новые аппаратные средства могут не поддерживать компиляторы исходного языка программ.
Недостапюк квалифицированного персонала Бывает, что для сопровождения программ на исходном языке невозможно найти достаточно квалифицированный персонал, особенно это касается программ, написанных на специфических языках, давно вышедших из употребления.
Изменения политики организации. Организация может принять решение о переходе на общий стандартный язык программирования, чтобы снизить затраты на сопровождение программных систем, поскольку сопровождение большого количества версий старых компиляторов невыгодно.
Недостаточно средств поддержки старого ПО. Поставщик компиляторов для старого языка программирования может уйти с рынка программных продуктов или прекратить поддержку своего продукта.
Процесс перевода исходного кода программ показан на рис. 28.4. Преобразование исходного кода будет эффективным только тогда, когда есть возможность выполнить основной перевод автоматически. Это может сделать либо специально созданная программа, либо коммерческая программа по конвертированию кода с одного языка в другой, либо система сопоставления с образцом. В последнем случае нужно создать список команд для описания перевода с одного языкового представления на другое. Параметризированные образцы исходного языка подвергаются сравнению и сопоставлению с такими же образцами в новом языке.
В некоторых случаях автоматизированный перевод становится невозможным. Структурные компоненты исходного кода могут не иметь соответствия в новом языке. Одна из причин этого в том, что исходный язык может содержать встроенные условные команды компиляции, которые не поддерживаются в новом языке. В такой ситуации придется настраивать и совершенствовать создаваемую систему вручную.
Анализ систем
Цель такого анализа — восстановление структуры и спецификации системы. Этот процесс не подразумевает изменения программ. Входными данными процесса анализа обычно служит исходный код системы. Однако зачастую даже он недоступен, тогда процесс анализа начинается с исполняемой программы.
Анализ систем не тождественен реииженирингу систем. Целью анализа является определение архитектуры и спецификации системы на основе ее исходного кода. Целью ре- инжениринга можно назвать создание усовершенствованной и удобной в сопровождении системы. Но, как показано па рис. 28.2, анализ системы может быть составной частью процесса реинжениринга.
Схема процесса анализа системы приведена иа рис. 28.5. Вначале с помощью автоматизированных средств проводится анализ структуры системы. В большинстве случаев этого недостаточно для воссоздания системной архитектуры. Требуется дополнительная работа с исходным кодом системы и с моделью ее структуры. Эта дополнительная информация сравнивается с данными, собранными во время автоматического анализа системы, и представляется в виде ориентированного графа, отображающего связи в исходном коде программ.
Репозиторий системной информации служит для сравнения структуры графа и кода. На основе ориентированного графа можно получить такие документы, как схемы структуры программ и данных, а также матрицы зависимостей. Матрицы зависимостей показывают места определения в программах системных объектов и ссылки на них. Процесс разработки документации повторяющийся, так как информация о системной структуре используется для дальнейшего уточнения информации, которая хранится в системном репозитории.
В процессе анализа полезны разные средс7ва просмотра программ, которые предоставляют различные системы представления программ и позволяют легко перемещаться но исходному коду. Например, с их помощью можно найти определения данных, а затем переместиться по коду к месту их использования. Описание некоторых подобных систем просмотра программ можно найти в [73, 263, 257].
После создания документации по системной архитектуре, в репозиторий вводится дополнительная информация, позволяющая восстановить системную спецификацию. Также обязательно ручное описание структуры системы. К сожалению, спецификацию невозможно создать автоматически из модели системы.
Совершенствование стру^^уры программ
Если в процессе эксплуатации наследуемой системы возникла необходимость оптимизировать использование памяти и имеются проблемы с пониманием того, как она работает, это означает, что система плохо структурирована. Управляющая структура наследуемых систем обычно значительно усложнена множеством безусловных переходов и нечеткой логикой программного кода. Регулярное сопровождение системы также не способствует сохранению системной структуры. После частых изменений некоторые фрагменты кода становятся неиспользуемыми, однако это можно обнаружить только после тщательного анализа программы.
В листинге 28.1 показан пример того, как усложненная логика управления может сделать трудной для понимания достаточно простую программу. Программа написана на языке, подобном FORTRAN, который часто использовался для создания программ такого рода. Программа не стала понятнее даже после того, как я дал переменным осмысленные имена. Это программа управления обогревателем. Панельный переключатель имеет положения On (Включено), Off (Выключено) и Controlled (Регулирование). Если система находится в режиме регулирования, она включается или выключается в зависимости от тер- мореле и установок таймера. Если обогреватель включен, переключатель Switch-heating выключает его, и наоборот.
Как правило, такая сложная логическая структура, как в коде листинга 28.1, образуется после внесения изменений в процессе сопровождения. Реализуя новые условия или связанные с ними действия, забывают об изменении структуры программы! Не задумываясь о перспективе, этот путь можно назвать кратчайшим и менее рискованным, так как он снижает вероятность возникновения большого количества ошибок в системе. Если же подумать о будущем, это решение приведет к трудному для понимания коду. Сложная структура кода может также появиться от желания программистов избежать дублирования кода. Ранее, когда на программы накладывалось требование ограничения памяти, это было обязательным условием.
Листинг 28.1. Программа с нечеткой логикой
Start: Get (Time-on, Time-off, Time, Setting, Temp, Switch) if Switch = off goto off if Switch = on goto on goto Cntrld off: if Heating-status = on goto Sw-off goto loop
on: if Heating-status = off goto Sw-on goto loop Cntrld: if Time = Time-on goto on if Time = Time-off goto off if Time < Time-on goto Start if Time > Time-off goto Start if Temp > Setting then goto off if Temp < Setting then goto on Sw-off: Heating-status := off goto Switch Sw-on: Heating-status := on Switch: Switch-heating loop: goto Start
В листинге 28.2 приведена та же самая программа, переписанная мной с использованием структурированных управляющих конструкций. Три положения переключателя (Оп, Off и Controlled) четко оЙреде^еУы и связаны с соответствующим кодом. Язык Java не был использован при написании этой программы потому, что исходная программа не являлась объектно-ориентированной.
Листинг 28.2. Структурированная программа loop
-- Get получает значения переменных из окружения системы Get (Time-on, Time-off, Time, Setting, Temp, Switch) ; case Switch of
when On => if Heating-status = off then
Switch-heating ; Heating-status := on ; end if ;
when Off=> if Heating-status = on then
Switch-heating ; Heating-status :=off ; end if ; when Controlled =>
if Time >= Time-on and Time <= Time-off then
if Temp > Setting and Heating-status = on then Switch-heating; Heating-status = off ; elsif Temp < Setting and Heating-status = off then
Switch-heating; Heating-status := on ; end if ;
•nd if ;
•nd case ;
•nd loop
В процессе реструктуризации программ можно также упрощать сложные условные операторы. В листинге 28.3 показан пример упрощения условного оператора, содержащего логический оператор отрицания not.
Листинг 28.3. Упрощение условия
Сложное условие
if not (А > В and (С < D or not (Е > F) ) ) . . .
Упрощенное условие
if А <= В and (С <= D or Е > F) . . .
В известной работе [50] доказано, что любую программу можно переписать с помощью простых условных операторов if-then-else и циклов while-loop, при этом можно исключить все безусловные операторы перехода. Эта теорема является основой автоматической реструктуризации программ. Этапы такого преобразования программ показаны на рис. 28.6. Сначала программа представляется в виде ориентированного граф, после чего создается структурированная программа без использования операторов перехода.
Созданный ориентированный граф показывает поток передачи управления в программе. К этому графу применяются методы упрощения и преобразования, в результате чего находятся и устраняются неиспользуемые части кода. После этого генерируется новая программа, при этом операторы безусловного перехода заменяются циклами и условными операторами. Такая программа может быть написана как на исходном языке, так и на любом другом (например, программу на языке FORTRAN можно конвертировать в программу на С).
Автоматизированный способ реструктуризации программ имеет свои проблемы.
Потеря комментариев. Если в программе есть встроенные комментарии, они будут утеряны в процессе реструктуризации.
Утрата документации. По той же причине обычно нарушается соответствие между новой программой и документацией на исходную программу. Однако в большинстве случаев это не так уж важно, поскольку документация и комментарии уже устарели.
Жесткие требования к компьютерной технике. Алгоритмы, встроенные в средства реструктуризации, отличаются высокой сложностью. Процесс реструктуризации больших программ, даже выполненный на современных быстродействующих компьютерах, будет занимать много времени.
Если программа находится под управлением данных и программные компоненты тесно связаны с используемыми структурами данных, реструктуризация кода не обязательно значительно улучшит программу. Если программа была написана с помощью редкого варианта языка программирования, стандартные средства преобразования структуры могут выполняться некорректно, поэтому неизбежно ручное вмешательство.
Иногда не стоит реструктуризировать все программы системы. Некоторые программы могут отличаться хорошим качеством, другие не подвергались большому количеству изменений, которые повредили бы их структуру. В работе [13] предлагается набор показателей для выявления тех программ, реструктуризация которых будет наиболее эффективной. Для этого можно использовать следующие показатели:
интенсивность сбоев в работе программы;
процентное соотношение кода, измененного на протяжении года;
сложность компонентов.
При преобразовании структуры программ также следует учитывать степень соответствия программ или системных компонентов существующим стандартам.