Помощь в написании студенческих работ
Антистрессовый сервис

Языковые преобразования в задачах реинжиниринга программного обеспечения

Диссертация: Языковые преобразования в задачах реинжиниринга программного обеспечения
ДиссертацияПомощь в написанииУзнать стоимостьмоей работы

Одной из наиболее распространенных форм реинжиниринга являются языковые преобразования (language conversion), подразумевающие преобразование устаревших программ в эквивалентные им по функциональности программы на том же или другом языке высокого уровня. Первоначально активные исследования в этой области сводились к совершенствованию методов так называемой транслитерации, т. е. прямолинейной… Читать ещё >

Языковые преобразования в задачах реинжиниринга программного обеспечения (реферат, курсовая, диплом, контрольная)

Содержание

  • Актуальность темы
  • История проекта RescueWare
  • Научный контекст работ по созданию RescueWare
  • Основные результаты диссертационной работы
  • Апробация работы
  • Благодарности
  • ГЛАВА 1. ОБЗОР ЗАДАЧ РЕИНЖИНИРИНГА
    • 1. 1. Реинжиниринг и его экономические предпосылки
    • 1. 2. Основные задачи реинжиниринга
      • 1. 2. 1. Возвратное проектирование
      • 1. 2. 2. Извлечение знаний
      • 1. 2. 3. Реструктуризация программ.¦¦¦¦
      • 1. 2. 4. Языковые преобразования
    • 1. 3. Смежные вопросы реинжиниринга
      • 1. 3. 1. Сопровождение программ
      • 1. 3. 2. Повторное использование программ
  • ГЛАВА 2. ТРУДНОСТИ, ВОЗНИКАЮЩИЕ ПРИ ЯЗЫКОВЫХ ПРЕОБРАЗОВАНИЯХ
    • 2. 1. О сложности языковых преобразований
    • 2. 2. Требования к средствам преобразования языков
    • 2. 3. Технические проблемы
      • 2. 3. 1. Преобразование типов данных
      • 2. 3. 2. Кобол в Visual Basic
      • 2. 3. 3. Кобол в Java
      • 2. 3. 4. OS/VS Cobol to VS Cobol II
      • 2. 3. 5. Turbo Pascal to Java
      • 2. 3. 6. Перевод языково-специфичных конструкций
      • 2. 3. 7. Проблемы поддержки сгенерированного текста
    • 2. 4. Обсуждение
    • 2. 5. Процесс преобразования языков

Актуальность темы

.

Программирование существует уже более 50 лет. За это время было написано огромное количество программ — согласно оценкам, приведенным в книге [50], объем созданного программного обеспечения превышает 800 миллиардов строк кода. Существует также более консервативная оценка [94], согласно которой объем реально используемых систем по состоянию на 1990 год составлял около 120 миллиардов строк кода. Кроме того, при создании программных систем использовались самые разнообразные языки программирования. Согласно оценкам из книги [53], 30% существующих в мире программ написаны на Коболе, 20% - на C/C++, 10% на Ассемблере, а остальные 40% программ написаны на одном из остальных распространенных языков программирования (утверждается, что к таким распространенным языкам имеет смысл отнести еще около 500 языков программирования [61]).

Объем написанного программного обеспечения (ПО) постоянно растет. С одной стороны, это обусловлено тем, что постоянно пишутся все новые и новые программы, но еще важнее то, что однажды написанные программы крайне медленно выходят из обращения. Многие программные системы живут десятилетиями и при этом не теряют своей актуальности. Так как технологии программирования развиваются очень быстро, то такие системы рано или поздно становятся устаревшими или унаследованными (legacy systems). Действительно, 220 миллиардов строк на Коболе говорят сами за себя.

Таким образом, одной из центральных проблем программной инженерии становится сопровождение и эволюция ПО. Исследования показывают, что от 67 до 80% всех затрат жизненного цикла программы приходится именно на этап сопровождения [64]. Тем не менее, с течением времени структура сопровождаемых программ обычно ухудшается, и стоимость сопровождения заметно возрастает. Этот этап жизненного цикла программ характеризуется возникновением так называемого волнообразного эффекта возникновения ошибок [103] и постепенным старением программ [38, 72].

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

Одной из наиболее распространенных форм реинжиниринга являются языковые преобразования (language conversion), подразумевающие преобразование устаревших программ в эквивалентные им по функциональности программы на том же или другом языке высокого уровня. Первоначально активные исследования в этой области сводились к совершенствованию методов так называемой транслитерации, т. е. прямолинейной замены синтаксиса одного языка на синтаксис другого [44, 57]. Однако такой подход не всегда позволяет получить программы приемлемого качества на целевом языке. Поэтому в последние годы также изучаются возможности преобразования языков с одновременным проведением других содержательных изменений, например, преобразование программ, написанных на процедурных языках, к эквивалентной объектно-ориентированной программе на современном языке [39, 47, 68, 118].

Другой актуальный вопрос реинжиниринга программ — это вовлечение человека в процесс трансформации устаревших систем. Потребность в участии человека связана с тем, что знания об устаревших системах постепенно теряются, и автоматическое восстановление таких знаний обычно не представляется возможным [12]. Таким образом, в процессе преобразования устаревшей системы желательно участие инженера, обладающего знаниями о рассматриваемой системе, и современные методики реинжиниринга должны предоставлять возможность учета и использования этих знаний [59].

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

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

История проекта RescueWare.

Проект RescueWare имеет долгую и интересную историю. Задача написания автоматизированного средства преобразования языков была сформулирована в американской компании SEER в начале 1990;х годов. Однако эта задача оказалась значительно сложнее, чем исходно предполагалось, и потому компания SEER начала искать потенциальных подрядчиков для выполнения этой работы в университетах. После нескольких неудачных попыток сотрудничества с американскими университетами в 1994 году представители компании SEER начали искать исполнителей за рубежом. По различным причинам одним из первых направлений поиска стала Россия, и в 1994 году коллектив компании «ТЕРКОМ» и лаборатории системного программирования СПбГУ приступил к решению этой задачи. Автор участвовал в этом проекте с 1995 года.

Исходно проект RescueWare был привязан к платформе HPS (High Productivity System), разрабатывавшейся и поддерживавшейся в то время компанией SEER. Поэтому первой задачей, поставленной перед нашим коллективом, было написание автоматического конвертора из языков Кобол и PL/I в Rules, внутренний язык системы HPS. Автор участвовал в создании синтаксического анализатора и написании синтеза целевого языка. Проект продолжался около двух с половиной лет и закончился созданием коммерческого продукта, получившего название RescueWare 1.0.

К этому моменту участники проекта пришли к выводу, что целевой язык был выбран неудачно, так как потенциальный рынок продукта, привязанного к платформе HPS, был слишком мал. Поэтому некоторые представители заказчика начали продвигать идею создания средства реинжиниринга, ориентированного на генерацию распространенных современных языков программирования, таких как С++, Java и Visual Basic. С помощью этого средства предлагалось выйти на новый для компании SEER рынок реинжиниринга устаревшего программного обеспечения. Однако перспективность этого рынка ставилась многими противниками этой идеи под сомнение.

Эти разногласия привели в 1997 к отделению небольшой группы сотрудников SEER и созданию абсолютно новой компании, получившей название Relativity Technologies. Эта компания предполагала создать новый продукт для преобразования устаревших систем и выйти с ним на рынок реинжиниринга, получая прибыль как от продаж продукта, так и от применения этого продукта к реальным устаревшим системам. Все задачи по разработке программного обеспечения для Relativity Technologies были возложены на все тот же российский коллектив.

В 1997 году началась разработка принципиально нового продукта, получившего рабочее название RescueWare NT. При создании этого продукта был учтен весь опыт, накопленный коллективом разработчиков в процессе работы над RescueWare 1.0. В частности, одним из важных решений была ориентация на многоязыковость средствас самого начала планировалось, что RescueWare будет поддерживать множество входных и выходных языков (хотя вначале исходный язык был только один — Кобол). значительно сложнее, чем исходно предполагалось, и потому компания SEER начала искать потенциальных подрядчиков для выполнения этой работы в университетах. После нескольких неудачных попыток сотрудничества с американскими университетами в 1994 году представители компании SEER начали искать исполнителей за рубежом. По различным причинам одним из первых направлений поиска стала Россия, и в 1994 году коллектив компании «ТЕРКОМ» и лаборатории системного программирования СПбГУ приступил к решению этой задачи. Автор участвовал в этом проекте с 1995 года.

Исходно проект RescueWare был привязан к платформе HPS (High Productivity System), разрабатывавшейся и поддерживавшейся в то время компанией SEER. Поэтому первой задачей, поставленной перед нашим коллективом, было написание автоматического конвертора из языков Кобол и PL/I в Rules, внутренний язык системы HPS. Автор участвовал в создании синтаксического анализатора и написании синтеза целевого языка. Проект продолжался около двух с половиной лет и закончился созданием коммерческого продукта, получившего название RescueWare 1.0.

К этому моменту участники проекта пришли к выводу, что целевой язык был выбран неудачно, так как потенциальный рынок продукта, привязанного к платформе HPS, был слишком мал. Поэтому некоторые представители заказчика начали продвигать идею создания средства реинжиниринга, ориентированного на генерацию распространенных современных языков программирования, таких как С++, Java и Visual Basic. С помощью этого средства предлагалось выйти на новый для компании SEER рынок реинжиниринга устаревшего программного обеспечения. Однако перспективность этого рынка ставилась многими противниками этой идеи под сомнение.

Эти разногласия привели в 1997 к отделению небольшой группы сотрудников SEER и созданию абсолютно новой компании, получившей название Relativity Technologies. Эта компания предполагала создать новый продукт для преобразования устаревших систем и выйти с ним на рынок реинжиниринга, получая прибыль как от продаж продукта, так и от применения этого продукта к реальным устаревшим системам. Все задачи по разработке программного обеспечения для Relativity Technologies были возложены на все тот же российский коллектив.

В 1997 году началась разработка принципиально нового продукта, получившего рабочее название RescueWare NT. При создании этого продукта был учтен весь опыт, накопленный коллективом разработчиков в процессе работы над RescueWare 1.0. В частности, одним из важных решений была ориентация на многоязыковость средствас самого начала планировалось, что RescueWare будет поддерживать множество входных и выходных языков (хотя вначале исходный язык был только один — Кобол).

К 1998 году появилась новая версия продукта, получившая название RescueWare 3.0, и начались проекты по применению этого продукта к реальным устаревшим системам. В этом же году была написана первая академическая статья, описывающая историю проекта в целом и архитектуры RescueWare, сложившейся к тому времени [122] (к сожалению, данная статья и весь сборник статей [121] по техническим причинам были опубликованы только в 2000 году).

Кроме того, в 1998 году начались работы по созданию «дополнений» (add-ons) к RescueWare. По иронии судьбы, первым дополнительным входным языком, поддержанным в RescueWare NT, стал язык HPS*Rules — тот самый язык, который служил целевым языком для RescueWare 1.0. С начала 1999 года автор возглавляет группу разработчиков, участвующих в создании именно этой подсистемы RescueWare.

В 1999 году в связи с резким увеличением количества работ по реинжинирингу конкретных систем в нашем коллективе появился отдел консалтинга. Для увеличения эффективности работы к участию в проектах этого отдела привлекались и разработчики инструментальных средств, В рамках таких работ в 2000 году автор принимал участие в переводе крупной промышленной системы из HPS*Rules в языки Кобол и Visual Basic. Проект длился около полугода, причем большая часть работы была выполнена во время длительной командировки автора в США. Опыт участия в подобных проектах позволил разработчикам получить совершенно иной взгляд на свои повседневные задачи создания инструментальных средств. В частности, с появлением первых проектов по реинжинирингу конкретных устаревших систем стало ясно, что любой реинжиниринг устаревшей системы требует активного участия человека.

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

• Поддержка процессов возвратного проектирования, включая средства анализа и навигации по исходным текстам, средства построения диаграмм, создание словарей системы, редокументация и т. п. [106, 7].

• Извлечение знаний, включая создание срезов программы и компонентизацию приложения [108].

• Генерация программ на современных языках программирования по устаревшей системе [110, 113]. На данный момент, в состав продукта входят универсальный конвертор из Кобола, PL/I и Adabas Natural в С++, Java и Visual Basic, а также конверторы из HPS*Rules в Кобол, Java и Visual Basic.

Научный контекст работ по созданию RescueWare.

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

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

Первыми книгами, с которыми мы ознакомились, стали книги [69, 20, 2]. Особенно полезной оказалась последняя из них. Эта книга, представляющая собой нечто среднее между справочником и учебным пособием, была выпущена в 1993 году в авторитетном издательстве IEEE Computer Society Press под редакцией известного исследователя проф. Роберта Арнольда (Robert Arnold). В каком-то смысле, эта книга представляет собой подведение основных результатов, полученных в данной области до 1993 года. Основу книги составили наиболее значимые статьи, опубликованные мировыми исследователями в различных журналах и представленные на международных конференциях. Кроме того, специально для книги был написан целый ряд обзорных статей по отдельным вопросам реинжиниринга.

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

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

Санкт-Петербургского государственного университета был выпущен сборник научных статей «Автоматизированный реинжиниринг программ» (под редакцией проф. А. Н. Терехова и А.А. Терехова) [121]. В этом сборнике было представлено 19 научных статей двадцати одного автора. Все эти статьи излагали различные технические и исследовательские результаты работ над проектом Rescue Ware. Постоянная и активная научная работа в области реинжиниринга продолжается в нашем коллективе и сегодня.

Основные результаты диссертационной работы.

В данной диссертационной работе получены следующие основные результаты:

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

2. Предложен метод оценки осуществимости языковых преобразований, основанный на сравнении выразительной мощности исходного и целевых языков программирования.

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

4. Предложен метод преобразования языков, основанный на эмуляции типов данных и конструкций, отсутствующих в целевом языке.

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

6. Предложена методология создания объектно-ориентированных программ по устаревшим системам.

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

Все основные результаты диссертационной работы являются новыми.

Апробация работы.

Результаты диссертации докладывались на семинаре Института системного программирования (2002 год, Москва), а также на конференциях по сопровождению программного обеспечения (ICSM 2001, Флоренция, Италия), сопровождению и реинжинирингу программного обеспечения (CSMR 2002, Будапешт, Венгрия) и средствам для объектно-ориентированных языков и систем (TOOLS ЕЕ 2000, София, Болгария). Часть результатов была опубликована в журнале IEEE Software.

Основные результаты работы изложены в 10 публикациях, написанных при непосредственном участии автора [120, 122, 123, 118, 104, 119, 90, 92, 91, 17].

Методы и полученные результаты данной диссертационной работы были реализованы как составные средства продукта RescueWare и успешно прошли практическую проверку на крупных проектах по преобразованию промышленных программных систем.

Благодарности.

Автор диссертации хотел бы выразить свою глубокую благодарность и признательность всем людям, прямо или косвенно помогавшим в работе над данной диссертацией:

• Участникам проекта RescueWare, особенно руководителям и архитекторам проекта (Лен Эрлих, Валентин Оносовский, Михаил Громов, Татьяна Попова, Александр Апрелев, Олег Плисс, Михаил Бульонков и многие другие).

• Соавторам статей (Крис Верхуф, Андрей Терехов-ст., Лен Эрлих, Дмитрий Булычев, Дмитрий Кознов, Александра Береснева).

• Коллегам, помогавшим мне улучшить текст статей (Карина Терехова, Дмитрий Банков, Анна Голодная, Гарри Снид, анонимные рецензенты).

• Неформальному научному руководителю, помогавшему мне повысить научный уровень исследований (Андрей Терехов-ст.).

• Всем авторам сборника «Автоматизированный реинжиниринг программ», который я редактировал.

• Студентам 4 курса, принявшим участие в организованном мною спецкурсе «Реинжиниринг программного обеспечения» .

• Родным и близким за моральную поддержку в процессе написания диссертации.

5.5.

Заключение

.

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

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

Предложенная методология иллюстрируется на примерах из промышленного проекта по преобразованию приложения из PL/I в Java. Обсуждается применимость предложенной методологии, в том числе, в промышленных проектах и в проектах, содержащих слабоструктурированные программы.

В заключение диссертации, приведем общую и уточненную схему методологии реинжиниринга, предложенной автором в данной диссертации (см. рис. 12):

Реструктуризация Реструктуризация.

Формализация Выделение языка проекта объектов.

Рис. 12. Окончательный вариант методологии реинжиниринга, предложенной в диссертации.

Предложенная методология реинжиниринга состоит из следующей последовательности шагов:

1. Анализ исходных программ, реструктуризация в терминах исходного языка и построение промежуточного представления (см. главу 2).

2. Настройка средства реинжиниринга на данный проект (см. главу 5).

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

4. Выделение классов на основе пользовательской информации или различных эвристик (см. главу 4).

5. Генерация программ на целевых объектно-ориентированных языках (см. главу 2).

Отметим, что этапы 2 и 4 являются необязательными. Эти шаги могут выполняться для улучшения качества порождаемого кода.

Все этапы предложенной автором методологии были реализованы в инструментальном средстве реинжиниринга RescueWare и были успешно применены на промышленных проектах по преобразованию устаревших систем (см. главы 3 и 5).

Показать весь текст

Список литературы

  1. Н. Agrawal, J. R. Horgan «Dynamic Program Slicing», 1. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, New York, June 1990, pp. 246−256.
  2. R. S. Arnold (ed.) «Software Reengineering», IEEE Computer Society Press, 1993, 676 pp.
  3. R. S. Arnold «Software Restructuring», Proceedings of IEEE, Vol. 77, No. 4, April 1989, pp. 607−617.
  4. R. S. Arnold, W. B. Frakes «Software Reuse and Reengineering», In 2., pp. 476−484.
  5. E. Ashcroft, Z. Manna «The translation of 'goto' programs in 'while' programs», Proceedings of the 1971IFIP Congress, Amsterdam, pp. 250−260
  6. C. Babcock «Restructuring eases maintenance», Computerworld, November 1987, pp. 19, 22.
  7. D. Baburin «Using Graph Representations in Reengineering», In Proceedings of the 6th Conference on Software Maintenance and Reengineering, Budapest, Hungary, March 2002.
  8. C. Bachmann «A CASE for Reverse Engineering», Datamation, July 1988
  9. J. W. Bailey, V. R. Basili «Software Reclamation: Improving Post-Development Reusability», In Proceedings of the 8tli National Conference on Ada Technology, US Army Communications-Electronics Command, Fort Monmouth, N.J., 1990, pp. 477—480 and 489−499.
  10. B. S. Baker «An Algorithm for Structuring Flowgraphs», Journal of the ACM, Vol. 24, No. 1, 1977, pp. 98−120.
  11. K.H. Bennett «Automated support of software maintenance», Information and Software Technology, Vol. 33, No. 1, 1991, pp. 74−85.
  12. T.J. Biggerstaff, B.G. Mitbander, D.E. Webster «Program Understanding and the Concept Assignment Problem», Communications of the ACM, May 1994, pp. 72−82.
  13. B. Boehm «Software Engineering Economics», Englewood Cliffs, N.J., Prentice-Hall, 1981.
  14. B. Boehm et al. «A Software Development Environment for Improving Productivity», Computer, June 1984, pp. 30−44.
  15. С. Bohm, G. Jacopini «Flow diagrams, Turing machines and languages with only two formation rules», Communications of the ACM, Vol. 9, No. 5, May 1966, pp. 366−371.
  16. D. Boulychev, D. Koznov, A.A. Terekhov «On Project-Specific Languages and Their Application in Reengineering», In Proceedings of the Sixth European Conference on Software Maintenance and Reengineering, Budapest, Hungary, March 2002, pp. 177— 185.
  17. M.G.J. van der Brand, M.P.A. Sellink, C. Verhoef «Current Parsing Techniques in Software Renovation Considered Harmful», In Proceedings of the International Workshop on Program Comprehension, Ischia, Italy, 1998, pp. 108−117.
  18. M.G.J. van den Brand, M.P.A. Sellink, C. Verhoef «Generation of Components for Software Renovation Factories from Context-Free Grammars», Science of Computer Programming, Vol. 36, No. 2−3, Mar. 2000, pp. 209−266.
  19. M. L. Brodie, M. Stonebraker «Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach», Morgan-Kaufmann, 1995, 210 pp.
  20. G. Caldiera, V. R. Basili «Identifying and Qualifying Reusable Software Components», Computer, Vol. 24, No. 2, February 1991, pp. 61−70.
  21. F.W. Calliss «Problems with Automatic Restructures», ACM SIGPLAN Notices, Vol. 23, No. 3, Mar. 1988, pp. 13−23.
  22. G. Canfora, A. Cimitile, A. De Lucia «Conditioned program slicing», In Information and Software Technology Special Issue on Program Slicing, Elsevier-Science B.V., Vol. 40, 1998, pp. 595−607.
  23. C. Cerf and V. Navasky «The Experts Speak — The Definitive Compendium of Authoritative Misinformation», Villard Books, New York, 1998
  24. Y. Chae and S. Rogers «Successful COBOL Upgrades: Highlights and Programming Techniques», John Wiley and Sons, New York, 1999, 288 pp.
  25. E. Chikosfky «CASE and Reengineering: From Archeology to Software Perestroika», Proceedings of the 12th International Conference on Software Engineering, 1990, p. 122
  26. E. Chikofsky, J. H. Cross II «Reverse Engineering and Design Recovery: A Taxonomy», IEEE Software, Vol. 7, No. 1, January 1990, pp. 13−17.
  27. C. Cifuentes, K.J. Gough «Decompilation of Binary Programs», Software: Practice and Experience, Vol. 25, No. 7, July 1995, pp. 811−829.
  28. I. Clafien, К. Hennig, I. Mohr, M. Schulz «CUI to GUI Migration: Static Analysis of Character-Based Panels», Proceedings of the 1st Euromicro Working Conference on Software Maintenance and Reengineering, Berlin, 1997.
  29. B. Cox «Object-Oriented Programming: An Evolutionary Approach», Addison-Wesley, Reading, MA. 1976.
  30. M. A. Cusumano, R. W. Selby «Microsoft Secrets», Simon & Schuster, New York, 1998, 512 pp.
  31. T. DeMarco, T. Lister «Peopleware Productive Projects and Teams», Dorset House, New York, 1987, p. 30.
  32. W. C. Dietrich jr., L. R. Hackman, F. Gracer «Saving a Legacy with Objects», Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'89), pp. 77−83.
  33. E. Dijkstra «Go to statement considered harmful», Communications of the ACM, vol. 11, no. 3, pp. 147−148, March 1968
  34. M. F. Dunn, J. C. Knight «Software Reuse in an Industrial Setting: a Case Study», In Proceedings of the International Conference on Software Engineering, 1991, pp. 329 338.
  35. S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, A. Mockus «Does Code Decay? Assessing the Evidence from Change Management Data», IEEE Transactions on Software Engineering, Vol. 27, No. 1, January 2001, pp. 1−12.
  36. L. H. Etzkorn, C. G. Davis «Automatically Identifying Reusable 00 Legacy Code», Computer, October 1997. P. 66−71.
  37. D. P. Freedman, G. M. Weinberg «Handbook of Walkthroughs, Inspections and Technical Reviews», Dorset House, 3rd edition, 1990
  38. E. S. Garnett, J. A. Mariani «Software Reclamation», Sofware Engineering Journal, May 1990, pp. 185−191
  39. R.L. Glass «Computing Calamities—Lessons Learned from Products, Projects, and Companies That Failed», Prentice Hall, Englewood Cliffs, N.J., 1999, pp. 190−191.
  40. R. L. Glass, R. A. Noiseux «Software Maintenance Guidebook», Englewood Cliffs, NJ: Prentice-Hall, 1981
  41. R. Gray, T. Bickmore, S. Williams, «Reengineering Cobol Systems to Ada,» Proc. Seventh Annual Air Force/Army/Navy Software Technology Conf., US Dept. of Defense, Hill Air Force Base, 1995.
  42. M. Harman, S. Danicic «Amorphous Program Slicing», In Proceedings of the 5th IEEE International Workshop on Program Comprehension, Dearborn, Michigan, USA, May 1997, pp. 70−79.
  43. M. A. Jackson «Principles of Program Design», Academic Press, London, 1975
  44. I. Jacobson, F. Lindstrom, «Re-engineering of Old Systems to an Object-Oriented Architecture», In Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA'91), ACM, New York, 1991, pp. 340 350.
  45. Y. Jang «Legacy Systems and Object Technology Workshop Summary», Addendum to the Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA'95), ACM, New York, 1995, pp. 176−179.
  46. C. Jones «Programming Productivity: Issues for the Eighties», 2nd edition, Los Angeles, IEEE Computer Society Press, 1986.
  47. C. Jones «Estimating Software Costs», McGraw-Hill, 1988.
  48. C. Jones «Applied Software Measurement», N.Y.: McGraw-Hill, 1991.
  49. C. Jones «Assessment and Control of Software Risks», Prentice Hall, Englewood Cliffs, N.J., 1994.
  50. C. Jones «The Year 2000 Software Problem Quantifying the Costs and Assessing the Consequences», Addison-Wesley, 1998
  51. B. Kernighan, P. J. Plauger «Software Tools», Addison-Wesley, Reading, MA. 1976. 338 pp.
  52. W.M. Klein, OldBOL to NewBOL: A COBOL Migration Tutorial for IBM, Merant Publishing, 1998.
  53. J. W. Klop «Term rewriting systems», In Handbook of Logic in Computer Science, Vol. II, Oxford University Press, 1992, p. 1−116.
  54. K. Kontogiannis et al., «Code Migration through Transformations: An Experience Report,» Proc. IBM Center for Advanced Studies Conf. (CASCON '98), IBM, Armonk, NY, 1998, pp. 1−12. Available at www.swen.uwaterloo.ca/~kostas/migration98.ps.
  55. B. Korel, J. Laski «Dynamic Program Slicing», Information Processing Letters, Vol. 29, No. 3, October 1988, pp. 155−163.
  56. W. Kozaczynski, J. Q. Ning, A. Engberts «Program Concept Recognition and Transformation», IEEE Transactions on Software Engineering, Vol. 18, No. 12, December 1992, pp. 1065−1075.
  57. W. Kozaczynski, J. Q. Ning «Automated Program Understanding by Concept Recognition», Automated Software Engineering Journal, 1(1): 61—78, March 1994.
  58. R. Lammel, C. Verhoef «Cracking the 500 Language Problem», IEEE Software, Vol. 18, No. 6, pp. 78−88.
  59. F. Lehner «Software Life Cycle Management Based on a Method for Phase Distinction», Euromicro Journal, August 1991, pp. 603−608.
  60. B. Lientz, E. B. Swanson «Software Maintenance Management», Addison-Wesley, 1980.
  61. В. Lientz, Е. В. Swanson, G. Е. Tompkins «Characteristics of application software maintenance», Communications of the ACM, Vol. 21, No. 6, 1978, pp. 466−471.
  62. A. de Lucia «Program Slicing: Methods and Applications», In Proceedings of the 1st IEEE International Workshop on Source Code Analysis and Manipulations, Florence, Italy, 2001, pp.142−149.
  63. Z.-Y. Liu, M. Baliantyne, L. Seward, «An Assistant for Re-Engineering Legacy Systems», In Proceedings of the 6th Conference on Innovative Applications of Artificial Intelligence, 1994. P. 95−102.
  64. A. J. Malton «The Migration Barbell», First ASERC Workshop on Software Architecture, August 2001, http://www.cs.ualbeita.cay~kenw/conf/awsa2001/papers/malton.pdf
  65. J. Martin, H. A. Muller «C to Java Migration Experiences», In Proceedings of the Sixth European Conference on Software Maintenance and Reengineering, Budapest, Hungary, March 2002, pp. 143−153.
  66. H. W. Miller «Reengineering Legacy Software Systems», Digital Press, 1997, 280 pp.
  67. J.C. Miller, B.M. Strauss «Implications of Automated Restructuring of COBOL», ACM SIGPLAN Notices, Vol. 22, No. 6, June 1987, pp. 76−82.
  68. S. Oualline, Practical С Programming, 3rd ed., O’Reilly & Assoc., Cambridge, Mass., 1997.
  69. D.L. Parnas «Software Aging», In Proceedings of the 16th International Conference on Software Engineering, May 1994, pp. 279−287.
  70. W. Polak, L.D. Nelson, T.W. Bickmore «Reengineering IMS databases to relational systems», In Proceedings of the 7th Annual Air Force/Army/Navy Software Technology Conference, Salt Lake City, April 1995.
  71. A. Quilici «A Memory-Based Approach to Recognizing Programming Plans», Communications of the ACM, Vol. 37, No. 5, May 1994, pp. 84−93.
  72. A. Quilici, S. Woods, Y. Zhang «Program Plan Matching: Experiments with a Constraint-Based Approach», Science of Computer Programming, Vol. 36,2000, pp. 285—302
  73. V. Rajlich, К. H. Bennett «A Staged Model for the Software Life Cycle», Computer, Vol. 33, No. 7, July 2000, pp. 66−71.
  74. C. Rich, R. C. Waters «Programmer's Apprentice», ACM Press, 1990. 238 pp.
  75. C. Rich, L. M. Wills «Recognizing a Program’s Design: A Graph-Parsing Approach», IEEE Software, Vol. 7, No. 1, January 1990, pp. 82−89.
  76. N. F. Schneidewind «The State of Software Maintenance», IEEE Transactions on Software Engineering, Vol. 13, No. 3, 1987, pp. 303−310.
  77. M.P.A. Sellink, H.M. Sneed, and C. Verhoef, «Restructuring of COBOL/CICS Legacy Systems,» Proc. Third European Conf. Maintenance and Reengineering, IEEE Computer Soc. Press, Los Alamitos, Calif., 1999, pp. 72−82.
  78. A. Sellink, C. Verhoef «Native Patterns», In Proceedings of the 5th IEEE Working Conference on Reverse Engineering, Honolulu, Hawaii, USA, 1998.
  79. A. Sellink, C. Verhoef «Scaffolding for Software Renovation», In Proceedings of the 4th Conference on Software Maintenance and Reengineering, Zurich, Switzerland, 2000, pp. 151−160.
  80. M. C. Smith, D. E. Mularz, T. J. Smith «CASE Tools Supporting Ada Reverse Engineering: State of the Practice», Proceedings of the Eighth Annual National Conference on Ada Technology, 1990, pp. 157−164
  81. H. M. Sneed «Economics of Software Re-engineering», Journal of Software Maintenance: Research and Practice, Vol. 3, No. 3, Sept. 1991, pp. 163−182.
  82. H. M. Sneed «Planning the Reengineering of Legacy Systems», IEEE Software, January 1995, Vol. 12, No. 1, pp. 24−34.
  83. H. M. Sneed «Reverse Engineering as a Bridge to CASE», Proceedings of the Seventh International Workshop on Computer-Aided Software Engineering (CASE'95). P. 304 317
  84. H. M. Sneed, Objektorientierte Softwaremigration Object-Oriented Software Migration., Addison Wesley Longman, Bonn, Germany, 1998.
  85. H. M. Sneed «Risks Involved in Reengineering Projects», Proceedings of WCRE, 1999, IEEE Computer Society Press, Atlanta, October 1999, pp. 204−212.
  86. H. M. Sneed, C. Verhoef «Reengineering the Corporation A Manifesto for IT Evolution», Encyclopedia of Software Engineering, 2001 (pages ??).
  87. A. A. Terekhov «Automated Extraction of Classes from Legacy Systems», In Proceedings of TOOLS EE, 2000.
  88. A. A. Terekhov «Automating Language Conversion: A Case Study», In Proceedings of the IEEE International Conference on Software Maintenance, 2001. P. 654−658.
  89. A. A. Terekhov, C. Verhoef «The Realities of Language Conversions», IEEE Software, November/December 2000, Vol. 17, No. 6, pp. 111−124.
  90. B. Toeter «Reuse of ABN-AMRO PowerBuilder Applications», M.Sc. thesis, University of Amsterdam, July 2001, 63 pp.
  91. W. Ulrich «The evolutionary growth of reengineering and the decade ahead», American Programmer, Vol. 3, No. 11, pp. 14−20.
  92. US National Bureau of Standards «Guidance on software maintenance», Special Publication No. 500−106, Washington, DC, 1983.
  93. C. Verhoef «Software Development is a Special Case of Maintenance», In Proceedings of the 3rd Annual Conference on Software Engineering and Applications, Scottsdale, Arizona, USA, October 1999.
  94. VS COBOL II. Application Programming Language Reference, 4th ed., IBM Corp., Armonk, N.Y., 1993
  95. R. C. Waters «Program Translation via Abstraction and Reimplementation», IEEE Transactions on Software Engineering, Vol. SE-14, No. 8, August 1988, pp. 1207−1228.
  96. B. W. Weide, W. D. Heyrn «Reverse Engineering of Legacy Code Exposed», In Proceedings of International Conference on Software Engineering, Seattle, WA, 1995, pp. 327−331.
  97. M. Weiser «Program Slicing», IEEE Transactions on Software Engineering, Vol. 10, No. 4, 1984, pp. 352−357.
  98. R. Widmer, COBOL Migration Planning, Edge Information Group, 1998.
  99. K. Yasumatsu and N. Doi, «SPiCE: A System for Translating Smalltalk Programs Into, а С Environment,» IEEE Transactions on Software Engineering, Vol. 21, No. 11, 1995, pp. 902−912.
  100. S. Yau, J.S. Collofello, T. MacGregor «Ripple effect analysis of software maintenance» // Proc. IEEE COMPSAC, 1978. P. 492−497.
  101. А. В. Береснева, А. А. Терехов «Анализ языка PL/I в системе RescueWare», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 268−277.
  102. Ф. П. Брукс-мл. «Мифический человеко-месяц, или как создаются программные системы», 2-е изд., СПб.: Символ-плюс, 1999,304 стр.
  103. М.А. Бульонков, Д. Е. Бабурин «HyperCode открытая система визуализации программ», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 165−183.
  104. Г. Буч «Объектно-ориентированный анализ и проектирование с примерами приложений на С++», 2-е издание, М.: «Издательство Бином», СПб.: «Невский диалект», 1999.560 с.
  105. А. В. Друнин «Построение срезов программ в задачах реинжиниринга», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 184−205.
  106. А.П. Ершов «Организация АЛБФА-транслятора», в сб. «АЛЬФА — система автоматизации программирования», Сиб.отд.изд-ва «Наука» Новосибирск, 1967
  107. Б. Казанский «Генерация программ на целевых языках в задачах реинжиниринга», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 118−144.
  108. В. Е. Каменский, А. В. Климов, С. Г. Манжелей, Л. Б. Соловская «Применение стандарта CORBA для унаследованных систем», в сб. «Вопросы кибернетики. Приложения системного программирования», выпуск 3, Москва, 1997
  109. С. В. Куке «Алгоритм анализа потоков данных», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 110−117.
  110. М. Мосиенко «Построение динамической поддержки для задач реинжиниринга», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 145−164.
  111. О. А. Плисс, К. Д. Волошин «Трансляция вызовов и переходов из Кобола в С++», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 83−102.
  112. О. А. Плисс, К. Д. Волошин «Устранение локальных GOTO», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 103−109.
  113. М. В. Попов «Преобразование программы к структурной на основе метода расклейки графа управления», дипломная работа, математико-механический факультет СПбГУ, 2000. 32 с.
  114. Б. Страуструп «Дизайн и эволюция языка С++», М.: ДМК Пресс, 2000. 448 с.
  115. А. А. Терехов «Автоматизированное разбиение устаревших программ на классы», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 229−250.
  116. А. А. Терехов, К. Верхуф «Проблемы языковых преобразований», Открытые системы, № 5−6, 2001, с. 54−62.
  117. А. Н. Терехов, А. А. Терехов «Перенос приложений и проблема 2000 года», Компьютер-Пресс, № 8, 1998, с. 92−96.
  118. А. Н. Терехов, А. А. Терехов (ред.) «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000, 332 с.
  119. А. Н. Терехов, J1. А. Эрлих, А. А. Терехов «Перспективы реинжиниринга», Компьютер-Пресс, № 8, 1999.
  120. А. Н. Терехов, JI. А. Эрлих, А. А. Терехов «История и архитектура проекта RescueWare», в сб. «Автоматизированный реинжиниринг программ», СПб, изд-во С.-Петербургского университета, 2000. С. 7−19.
Заполнить форму текущей работой

Сессия? Спокойно!