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

• Автор: Терехов, Андрей Андреевич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2002
• Место защиты: Санкт-Петербург
• Количество страниц: 127 с. : ил

СОДЕРЖАНИЕ
ВВЕДЕНИЕ.

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

История проекта ИеясиеХУаге

Научный контекст работ по созданию кеБсиеХУаге

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

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

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

ГЛАВА 1. ОБЗОР ЗАДАЧ РЕИНЖИНИРИНГА

1.1. Реинжиниринг и его экономические предпосылки.

1.2. Основные задачи реинжиниринга

1.2.1. Возвратное проектирование
1.2.2. Извлечение знаний
1.2.3. Реструктуризация программ
1.2.4. Языковые преобразования
1.3. Смежные вопросы реинжиниринга. 0
1.3.1. Сопровождение программ.
1.3.2. Повторное использование программ.
ГЛАВА 2. ТРУДНОСТИ, ВОЗНИКАЮЩИЕ ПРИ ЯЗЫКОВЫХ
ПРЕОБРАЗОВАНИЯХ.
2.1.0 сложности языковыт преобразовании..
2.2. Требовании к средствам преобразования языков.
2.3. Технические проблемы
2.3.1. Преобразование типов данных
2.3.2. Кобол в Vi i.
2.3.3. Кобол в v.
2.3.4. V V II
2.3.5. v
2.3.6. Перевод языковоспецифичных конструкций.
2.3.7. Проблемы поддержки сгенерированного текста
2.4. Обсуждение.
2.5. Процесс преобразования языков.
2.6. Заключение
ГЛАВА 3. ОПИСАНИЕ КОНКРЕТНОГО ПРОЕКТА ПО ПРЕОБРАЗОВАНИЮ ЯЗЫКОВ.
3.1. Краткое описание проекта ..
3.2. Особенности языка ..
3.3. Автоматизация решения задачи
3.4. Процесс конвертации и ею трудности
3.4.1. Преобразование в Кобол
3.4.2. Преобразование в V.
3.5. Обсуждение.
3.5.1. Программные факторы, влияющие на уровень автоматизации при языковых преобразованиях
3.5.2. Экономические соображения при разработке автоматизированных средств преобразования языков
3.5.3. Индустриальная проблема нахождение компромисса между поставщиком услуг по реинжинирингу и заказчиком.
3.6. Заключение .
ГЛАВА 4. ИЗВЛЕЧЕНИЕ КЛАССОВ ИЗ УСТАРЕВШЕЙ СИСТЕМЫ
4.1. Краткое изложение предлагаемого подхода .
4.2. Предварительная структуризация программ.
4.2.1. Выделение процедур
4.2.2. Локализация или полное уничтожение .
4.2.3. Локализация данных.
4.2.4. Оптимизирующие преобразования
4.3. Переход к объектноориентированным программам
4.3.1. Попытка создания автоматического решения.
4.3.2. Некоторые эвристики для разбиения устаревших программ на классы
4.3.3. Диалоговый процесс выделения классов.
4.3.4. Недостатки предложенного подхода и возможности дальнейшего усовершенствования
4.4. Пример преобразования программы к объектноориентированному виду
4.5. Другие подходы к созданию объектов.
4.5.1. Генерация класса, соответствующего всей прог рамме.
4.5.2. Создание объектных интерфейсов к устаревшим программам.
4.5.3. Генерация классов по срезам программ.
4.5.4. Перепроектирование с помощью средств
4.6. Заключение.
ГЛАВА 5. ИСПОЛЬЗОВАНИЕ ПРОЕКТНООРИЕНТИРОВАННЫХ НЕФОРМАЛЬНЫХ ЗНАНИЙ ПРИ РЕИНЖИНИРИНГЕ.
5.1. Связанные работы.
5.2. Формальная семантика н неформальные знания.
. Интерактивное извлечение языка, характерного для данного проекта
5.3.1. Понимание устаревших программ и настройка инструментальных средств.
5.3.2. Уточненная схема процесса извлечения языка проекта
5.3.3. Настраиваемая генерация.
5.4. Обсуждение
5.5. Заключение
ЛИТЕРАТУРА


Поэтому первой задачей, поставленной перед нашим коллективом, было написание автоматического конвертора из языков Кобол и PL/I в Rules, внутренний язык системы HPS. Автор участвовал в создании синтаксического анализатора и написании синтеза целевого языка. Проект продолжался около двух с половиной лет и закончился созданием коммерческою продукта, получившего название RescueWare 1. К этому моменту участники проекта пришли к выводу, что целевой язык был выбран неудачно, так как потенциальный рынок продукта, привязанного к платформе I IPS, был слишком мал. Поэтому некоторые представители заказчика начали продвигать идею создания средства реинжиниринга, ориентированного на генерацию распространенных современных языков программирования, таких как C++, Java и Visual Dasic. С помощью этого средства предлагалось выйти на новый для компании SEER рынок реинжиниринга устаревшего программного обеспечения. Однако перспективность этого рынка ставилась многими противниками этой идеи под сомнение. Эти разногласия привели в к отделению небольшой группы сотрудников SEER и созданию абсолютно новой компании, получившей название Relativity Technologies. Эта компания предполагала создать новый продукт для преобразования устаревших систем и выйти с ним на рынок реинжиниринга, получая прибыль как от продаж продукта, так и от применения этого продукта к реальным устаревшим системам. Все задачи по разработке программного обеспечения для Relativity Technologies были возложены на все тот же российский коллектив. В году началась разработка принципиально нового продукта, получившего рабочее название RescueWare NT. При создании этого продукта был учтен весь опы т, накопленный коллективом разработчиков в процессе работы над RescueWare 1. В частности, одним из важных решений была ориентация на многоязыковость средства -с самого начала планировалось, что RescueWare будет поддерживать множество входных и выходных языков (хотя вначале исходный язык был только один - Кобол). C год>' появилась новая версия продукта, получившая название Rescue Ware 3. В этом же году была написана первая академическая статья, описывающая историю проекта в целом и архитектуры Rescue Ware, сложившейся к тому времени [2] (к сожалению, данная статья и весь сборник статей [1] по техническим причинам были опубликованы только в году). Кроме того, в году начались работы по созданию "дополнений" (add-ons) к Rescue Ware. По иронии судьбы, первым дополнительным входным языком, поддержанным в RescueWarc NT, стал язык HPS*Rulcs - гот самый язык, который служил целевым языком для Rescue Ware 1. С начала года автор возглавляет группу разработчиков, участвующих в создании именно этой подсистемы RescueWare. В году в связи с резким увеличением количества работ по реинжинирингу' конкретных систем в нашем коллективе появился отдел консалтинга. Дія увеличения эффективности работы к участию в проектах этого отдела привлекались и разработчики инструментальных средств. В рамках таких работ в году автор принимал участие в переводе крупной промышленной системы из HPS*Rules в языки Кобол и Visual Basic. Проект длился около полугода, причем большая часть работы была выполнена во время длительной командировки автора в США. Опыт участия в подобных проектах позволил разработчикам получить совершенно иной взгляд на свои повседневные задачи создания инструментальных средств. В частности, с появлением первых проектов по реинжинирингу конкретных устаревших систем стало ясно, что любой реинжиниринг устаревшей системы требует активного участия человека. Поэтому RescueWare стало постепенно обрастать средствами понимания устаревших программ и извлечения знаний, превращаясь в полноценную интерактивную систему реинжиниринга. Поддержка процессов возвратного проектирования, включая средства анализа и навигации по исходным текстам, средства построения диаграмм, создание словарей системы, редокументация и т. Извлечение знаний, включая создание срезов программы и компонентизацию приложения [8]. Генерация программ на современных языках программирования по устаревшей системе [0, 3].