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

ВВЕДЕНИЕ. ЗАДАЧИ РЕИНЖИНИРИНГА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Бизнес и технологии.

Ближайшие цели: Интернет и e-commerce.

XML и электронный обмен данными.

Пути развития устаревших систем.

Извлечение знаний из устаревших систем.

Исторический контекст диссертационной работы.

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

ГЛАВА 1. ОБЗОР СУЩЕСТВУЮЩИХ МЕТОДОВ РЕИНЖИНИРИНГА УСТАРЕВШИХ

ПРОГРАММ. screen scrapers.

Переработка интерфейсов.

Интеграция среднего уровня.

Среда EAI и серверы приложений.

Proxy-серверы старых комплексов.

Извлечение знаний.

Перенос старых комплексов.

ГЛАВА 2. ПРИНЦИПЫ ПОСТРОЕНИЯ RESCUEWARE.

Архитектура RescueWare с точки зрения пользователя.

Извлечение знаний в RescueWare.

Платформы.

Среды э-коммерческой интеграции компонентов.

Внутренняя архитектура RescueWare.

Трудности реализации репозитория.

Ориентация на множество входных и выходных языков.

Ослабленные синтаксические анализаторы.

RescueWare SDK.

Будущие направления развития.

Дополнительные исходные и целевые платформы.

Возникающие стандарты отрасли.

Общие тенденции отрасли.

Сквозная генерация.

Дальнейшее развитие средств анализа.

ГЛАВА 3. ПРЕДЛАГАЕМАЯ МЕТОДОЛОГИЯ РЕИНЖИНИРИНГА.

Системная инвентаризация.

Планирование работ по проекту.

Системный анализ.

Преобразование интерфейсов.

Преобразование программной логики.

Извлечение знаний.

Разбиение приложений.

Генерация бизнес-объектов.

Преобразование данных.

ГЛАВА 4. КОМПОНЕНТИЗАЦИЯ МОНОЛИТНЫХ ПРИЛОЖЕНИЙ.

Ускоренный перенос приложений.

Подход, основанный на извлечении знаний.

Выделение независимых компонент.

Начальная компонентизация.

ГЛАВА 5. ОПЫТ ПРАКТИЧЕСКОГО ВНЕДРЕНИЯ ПРЕДЛОЖЕННЫХ МЕТОДОВ.

Модернизация ПО медицинской фирмы.

Модернизация большой информационной системы.

Система снабжения ВВС США.

Современные информационные технологии являются областью постоянного роста, причем темпы этих изменений поразительны. Одной из основных причин для этого является невероятно быстрая модернизация аппаратных платформ, которая вот уже более 25 лет следует закону Мура, гласящему, что производительность аппаратного обеспечения увеличивается в два раза каждые 18 месяцев. Несмотря на многократно высказывавшиеся мнения о приближении человечества к физическим границам роста вычислительной мощности, закон Мура все еще действует [А11ап2002]. Однако прогресс в области аппаратного обеспечения неизбежно ведет и к увеличению простора для творчества при создании программных средств. Рано или поздно все новые возможности компьютеров находят свое применение в программных продуктах, и тогда программистам снова начинает не хватать имеющихся в их распоряжении памяти или тактовой частоты, и все начинается сначала.

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

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

Бизнес и технологии

Одной из основных тенденций нашего времени является увеличение значимости использования технологий. Человечество постепенно переходит в новую эру - информационную. Столь коренного изменения всех отраслей деятельности не происходило со времен индустриальной революции [Tofflerl991]. Кратко обрисуем контуры этих преобразований.

На начальном этапе этого процесса происходило внедрение компьютеров в повседневную деятельность, что потребовало перестройки мышления людей, общающихся с ними. Процитируем академика Ершова: "Тысячи профессий меняют свое лицо. Миллионы людей - от управляющих, операторов производства и наладчиков до машинисток, банковских служащих и секретарей - садятся за полностью переоборудованные рабочие места, на которых ЭВМ становится их партнером и собеседником. И если даже этот партнер дружествен и надежен, у работника должна произойти глубокая психологическая и квалификационная перестройка для того, чтобы сохранить свою роль и - более того - свое достоинство в новой обстановке" [Ершов1982]. Это позволило существенно повысить эффективность работы человека в некоторых областях его деятельности.

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

Традиционная модель этого процесса приблизительно такова: компания арендует помещение для магазина, нанимает продавцов, прогнозирует читательский интерес, на базе полученного прогноза закупает книги у издательств и организует рекламную кампанию. Только после всех описанных вложений продажа книг дает некоторый доход, за счет которого можно покрыть затраты. С момента изобретения книгопечатания подобная модель деятельности была единственной. Самой крупной книготорговой компанией в течение многих лет была компания Barnes & Noble.

В 1995 году в Америке была создана компания Amazon.com, которая занималась продажей книг исключительно через Интернет. За счет ориентации на Интернет этой компании удалось принципиально снизить стоимость процесса, так как отпала необходимость в аренде помещений, оплате труда продавцов и даже в прогнозировании рынка. Дело в том, что Amazon.com покупает книги только после получения конкретного заказа на них. Таким образом, из процесса с вложением денег (инвестиционного) удалось получить процесс с притоком денег (прибыльного).

В результате, на сегодняшний день Amazon.com стал крупнейшей в своей области компанией, в несколько раз превосходящей всех своих конкурентов, а Barnes & Noble и другие подобные компании пытаются выправить положение на рынке за счет создания аналогичных компаний, занимающихся продажей книг через Интернет (в случае Barnes & Noble - это BarnesAndNoble.com).

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

Ближайшие цели: Интернет и e-commerce

Сила перемен, вызванных появлением электронной коммерции (э-коммерции), такова, что принципы работы многих организаций, занимающихся информационными технологиями (ИТ), претерпевают революционные изменения. Так называемая "эпоха Интернета", еще недавно характерная только для индустрии коммерческого программного обеспечения, вызвала изменения и в традиционно неторопливых корпорациях, косвенно зависящих от ИТ. В отличие от революции, связанной с подходом клиент/сервер, движущей силой которой были прежде всего технические организации, подпитывавшие ее изнутри, инициативы в области э-коммерции предопределены реалиями конкурентной борьбы во внешнем мире — мире бизнеса. За последние несколько лет электронно-коммерческие инициативы прошли путь развития от рекламных стендов корпораций до критически важных компонентов моделей ведения дел на предприятиях (см. рис. 1).

Технология Бизнес

Рис. 1. Сближение технологии и бизнеса

Огромную роль в успешном внедрении новых технологий играет Интернет. Переход от персональных компьютеров и локальных сетей к глобальному информационному сообществу открыл целый спектр возможностей. Широкомасштабное использование возможностей Интернета в коммерческих целях пока еще только начинается. Возможно, это связано с тем, что на начальном этапе такое использование было затруднено по причинам как технологического характера (низкая пропускная способность и недостаточная выразительная мощность), так и психологического (трудность переноса обычной деятельности компании в нематериальное пространство, вызванное пренебрежительным отношением к Интернету). Поэтому в течение многих лет коммерческие организации были представлены в Интернет только материалами рекламного характера. Но рекламный листок все чаще превращается в "виртуальный прилавок", то есть в существенную, а иногда и единственную часть бизнеса. При этом привлекательность Интернета растет с каждым годом, так как количество пользователей Интернета и объем передаваемых данных возрастают по закону, аналогичному закону Мура [Roberts2000].

Поэтому по данным компании Forrester Research в 1998 году общий оборот торговли по Интернету (общеупотребительны термины e-commerce или е-business) только в США составил около 43.1 миллиарда долларов, что почти в два раза больше, чем бюджет России на тот же год!

Своеобразным подтверждением состоятельности рынка e-commerce может служить тот факт, что такая крупная компания, как General Electric с 2000 года покупает все материалы для производства только через Интернет. Утверждается, что такое решение помогает компании сэкономить от 500 до 700 миллионов долларов в год. Вероятно, позиция General Electric привлечет на рынок е-commerce множество новых компаний. Вообще, прогнозируемые темпы роста этого рынка чрезвычайно высоки - по оценкам компании Forrester Research в 2003 году ожидается общий оборот, равный 1.3 триллиона долларов.

Очень ярко о тенденциях развития бизнеса высказался СЕО компании Intel Энди Гроув в интервью, данном им газете USA Today в 1999 году: "Через пять лет такое понятие, как компания, ориентированная на Интернет, уже не будет существовать, так как все компании будут работать в Интернет— или умрут".

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

XML и электронный обмен данными

Последним словом в технологиях, поддерживающих решение задач е-commerce, являются язык разметки документов XML (extensible Markup Language) и электронный обмен данными (EDI - Electronic Data Interchange). Остановимся на них поподробнее.

Язык XML задумывался как замена HTML, но вопреки широко распространенному ныне заблуждению, он не является его расширением - между этими языками существует качественная разница. Скорее, XML можно считать подмножеством общего языка разметки документов SGML (Standard Generalized Markup Language).

До появления XML перед создателями структурированных документов вставала непростая дилемма. Можно было хранить документы в SGML (как это сделано, например, в Adobe PageMaker) и, пользуясь его огромной выразительной мощностью, решать самые сложные задачи представления данных. Но в таком случае возникали проблемы с переносом этих данных в Интернет, так как SGML очень сложен и практически не поддерживается современными броузерами. С другой стороны, можно было писать документы на HTML и таким образом мгновенно добиваться их совместимости со стандартами Интернета. Однако HTML имеет жестко заданную структуру, и это ограничивает его возможности при решении многих серьезных задач.

XML призван занять промежуточную позицию - он не так сложен как SGML, но с другой стороны, сохраняет его основные выразительные возможности [Walsh1997].

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

Эти проблемы можно решить с помощью использования XML. Например, для описания цены какого-либо предмета можно создать тэг <price> и тогда в ответ на соответствующий поисковый запрос по XML-странице можно дать однозначный ответ. Такая система тэгов может быть уникальной для данной страницы или общей для целых отраслей индустрии или науки. Начало этой унификации уже положено такими системами как MathML (Mathematical Markup Language, язык для описания уравнений и формул).

Другая концепция - электронный обмен данными - представляет собой стандартизованный и независимый от типа платформ способ обмена деловыми документами между компаниями. Формат данных для EDI, описанный впервые стандартом ANSI XI2 в США, ныне определяется международным стандартом ISO 9735 EDIFACT.

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

Использование EDI существенно снижает затраты на взаимодействие партнеров по бизнесу и уже сегодня очень широко распространено. По оценкам консалтинговой группы J.P.Morgan, 950 из 1000 самых богатых компаний США используют EDI для своих коммерческих приложений. Интересный обзор перспектив можно найти в [Densmorel998],

В последнее время EDI стала сближаться с XML. Идея состоит в том, что обмен данными по-прежнему использует EDI, а для представления данных в Web используются XML-документы. Таким образом, использование XML в качестве стандарта хранения данных в сети может сократить расходы на поиск необходимых товаров.

Таким образом, подобно тому, как Java предоставила программистам возможность создавать платформенно-независимые программы, XML и EDI дают возможность использовать платформенно-независимые данные [Lear1999].

Пути развития устаревших систем

Насущная необходимость срочно выходить на рынок, в сочетании с потребностью в крепкой технической инфраструктуре, создает огромный прессинг для ИТ-отделов корпораций, вынуждая их решать чрезвычайно трудную задачу по скорейшему приобщению своих фирм к миру э-коммерции за счет использования новейших технологических решений. Существуют три классические стратегии развития устаревших систем [Ransoml998, Терехов1998], пользуясь которыми, организации, работающие в сфере ИТ, могут обеспечить приобщение своих систем к миру э-коммерции. Ниже дается краткая характеристика этих стратегий.

1. Покупать или самим создавать новые приложения. Этот подход основан на самостоятельной разработке новых приложений или же приобретении таких пакетов приложений, как системы ERP (например, SAP, Ваап или Peoplesofit). Хотя есть много причин, которые могут подтолкнуть организацию к выбору этой стратегии, чаще всего ею пользуются, когда необходимые функциональные средства и технология либо отсутствуют, либо чрезвычайно устарели.

2. Интегрировать новые приложения со старыми. Данная стратегия включает в себя процесс распознавания тех или иных старых приложений либо отдельных старых "бизнес-правил" (логически цельных частей алгоритмов) и заключения их в оболочку для вторичного использования новыми приложениями. Рентабельность этой стратегии часто бывает обусловлена состоянием исходных материалов. Применяемые средства тут могут варьироваться от так называемых screen scrapers (т. е. технологий, подменяющих интерфейс пользователя)1 до

1 К сожалению, достаточно трудно подобрать краткий эквивалент этого английского термина, поэтому мы решили оставить данное словосочетание без перевода. л оболочек типа интерфейсов прикладных программ (API) и сложных процедур вычленения бизнес-правил и компонентизации.

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

Каждая из вышеназванных стратегий занимает свое место в деятельности по развитию информационно-технологической инфраструктуры, и все они служат одной общей цели — поддерживать модель бизнеса данной организации. Однако опора на старые системы, предусматриваемая стратегиями 2 и 3, обеспечивает наивысшую степень гибкости при разработке и внедрении новых приложений в рамках ИТ-инфраструктуры, имеющейся в организации на данный момент. Старые, или унаследованные системы (legacy systems) — это имеющееся в распоряжении фирмы богатство выношенных и апробированных функциональных возможностей, реализованных на стабильных платформах, прошедших проверку временем [Brodiel995]. За счет включения различных составляющих старой системы в свои электронно-коммерческие начинания корпорация получает возможность заложить прочную основу для новых технологических решений, нацеленных на качество, которые могут быть разработаны ею в "эпоху Интернета".

Извлечение знаний из устаревших систем

Сразу оговоримся, что чаще всего не стоит сразу же отказываться от существующей системы в пользу написания новой "с чистого листа", ведь многие алгоритмы, накопленные в устаревшей системе, остаются актуальными. Кроме

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

Значительно более эффективной практикой является реинжиниринг с помощью извлечения знаний (knowledge mining) из устаревшей системы [Paul-son2000]. При таком подходе вначале строится каркас нового приложения, ориентированного на e-commerce. Понятно, что такой каркас никак не может быть получен из устаревшей системы - его необходимо проектировать и создавать заново.

Затем устаревшая система анализируется, и из нее извлекаются так называемые бизнес-правила (business rules). Считается, что именно в бизнес-правилах сосредоточены основные знания о системе, хотя, разумеется, необходимо восстанавливать утраченные знания и о схемах данных, и об интерфейсах, и о способах применения. Выделенные бизнес-правила оформляются в отдельные модули, определяются входные и выходные параметры, удаляются неиспользуемые участки кода и т.д. Итогом этой деятельности должны стать бизнес-правила, оформленные в виде готовых к использованию компонент.

Наконец, полученные бизнес-правила встраиваются в каркас приложения. Тем самым обеспечивается выигрыш в эффективности за счет переиспользования некоторых программ или даже целых систем. Обычно удается переиспользовать различные алгоритмически независимые части (вычисления, поддержка целостности и безопасности, обработка данных и т.д.). За счет этого удается существенно сократить время выполнения проектов по сравнению с написанием их "с нуля".

Данный процесс эффективен только при наличии мощных автоматизированных средств поддержки реинжиниринга. Данная диссертационная работа посвящена описанию методологии и инструментального средства реинжиниринга RescueWare, созданных под научным руководством автора диссертации в компаниях Relativity Technologies и "ЛАНИТ-ТЕРКОМ".

Исторический контекст диссертационной работы

В 1980-х годах автор диссертации участвовал в масштабных работах по автоматизации одного из крупнейших банков мира First Boston Bank. В процессе работ оказалось, что многие алгоритмы деятельности банка существуют только в виде текстов программ. Разумеется, когда-то существовали целые тома описаний бизнес-процессов, нормативно-справочная документация, различные регламенты и т.п., но с течением времени вся эта документация безнадежно устарела, поскольку менялись правила работы банка, налоговые инструкции, видоизменялись сами бизнес-процессы. Все эти изменения, безусловно, отражались в программах, но далеко не всегда отражались в соответствующих документах. По прошествии девяти-десяти лет практически любой бизнес-процесс был адекватно документирован только в текстах программ. С другой стороны, за такой долгий период многие авторы программ уходили с работы, умирали или становились большими начальниками. В любом случае, со временем в организации исчезали люди, способные ответить на технические вопросы о программах. Дополнительную трудность представлял тот факт, что за 10 лет менялись компьютеры, операционные системы, базы данных, средства обеспечения транзакций, диалоговые средства и т.д.

Именно в этот момент автор диссертации пришел к выводу о необходимости создания специальных средств реинжиниринга унаследованного программного обеспечения. Эти идеи были просты на вид, и казалось, что их реализация не составит особого труда. Автор диссертации предложил реализовать эти идеи нескольким группам ученых из различных университетов так называемого Исследовательского Треугольника (Research Triangle) в штате Северная Каролина. Однако ни одна из этих групп не смогла предложить практически полезных и масштабируемых решений.

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

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

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

Самая первая коммерческая версия системы RescueWare создавалась как средство преобразования бизнес-приложений, написанных на Коболе, в язык Rules, являющийся основой технологии SEER*HPS [Терехов2000б]. К моменту начала работ казалось, что эта задача ничем не отличается от задачи создания обычного компилятора Кобола, только вместо объектного кода необходимо генерировать программу на языке Rules. Более того, авторы предполагали, что на вход создаваемой системе реинжиниринга будут подаваться преимущественно отлаженные программы, успешно работающие в течение нескольких лет, поэтому нет необходимости создавать истинно диалоговую систему (сообщения об ошибках, привязка к исходному тексту, встроенные текстовые редакторы и тем более отладчики). В итоге был сделан вывод, что создаваемая система может запускаться в пакетном режиме. В результате, пользователь мог воспринимать процесс реинжиниринга как "черный ящик", на вход которому подаются исходные программы, а на выходе генерируются эквивалентные им программы на целевых языках.

Однако во время работы над RescueWare for SEER* HPS выяснилось, что задача реинжиниринга значительно сложнее обычной трансляции программ и требует более мощных методов. Это вызвано следующими особенностями реинжиниринга по сравнению с обычной трансляцией:

• к генерируемым программам предъявляется требование возможности сопровождения и развития (в отличие от обычной трансляции в ассемблер или машинный код);

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

• не все конструкции исходных языков имеют точные аналоги в целевых языках (особенные трудности возникают в тех случаях, когда целевой язык беднее, чем исходный, как это было в случае с трансляцией программ на Коболе в Rules), поэтому на практике некоторые особо сложные конструкции, не имеющие аналогов в целевых языках, не могут быть оттранслированы автоматически и оставляются для ручного перевода [Terekhov2000];

• в процессе перевода может потребоваться проведение анализа и визуализации исходных текстов с целью восстановления утерянных знаний о системе [Breuerl991] путем использования методов возвратного проектирования (reverse engineering).

Поэтому попытки применения RescueWare for SEER*HPS на практике вызывали огромные трудности: перед каждым новым проектом по реинжинирингу приходилось дорабатывать сам продукт RescueWare, чтобы успешно "бороться" с теми или иными особенностями системы. После нескольких случаев применения средства RescueWare for SEER* HPS на практике разработчикам системы стало ясно, что невозможно проводить реинжиниринг устаревших систем без участия человека.

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

Для этого в RescueWare появился целый класс визуальных средств, таких как HyperCode, позволяющий визуализировать программы на различных языках и осуществлять легкую навигацию по ним, Diagrammer, предназначенный для создания диаграмм отношений между различными программными компонентами и т.п. [Бульонков2000]

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

На этом этапе стало совершенно очевидно, что прежде чем каким-либо образом преобразовывать старую систему, нужно предварительно разбить ее на компоненты. Конечной целью такого разбиения является превращение большого жестко связанного программного блока в набор отдельных и независимых компонент. Такие компоненты затем могут быть размещены в распределенной многоплатформенной среде и связаны воедино с помощью объектных брокеров, таких как COM, Java Beans или CORBA.

Один особенно интересный метод разбиения программ на компоненты был основан на отделении их деловой, содержательной части от технической инфраструктуры. Этот метод, названный Business Rules Extraction (извлечение бизнес-правил), позволял "отсеять" весь зависимый от платформы код, например, управление транзакциями, управление памятью и обмен информацией между процессами, от лежащих в его основе содержательных команд. Извлеченные таким образом "бизнес-правила" составляют основу новой системы и автоматически переносятся на новую платформу без каких-либо изменений. В то же время вся техническая инфраструктура отбрасывается и затем вновь переписывается на заданной целевой архитектуре.

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

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

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

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

Автор диссертации хотел бы выразить свою глубокую благодарность своим американским коллегам из компании Relativity Technologies (Вивек Вадва, Майк Оара, Рич Кронхейм), которые поверили в идеи, изложенные в данной диссертации, участвовали в нахождении соответствующего финансирования этого проекта и морально поддерживали автора все эти годы.

Основной вклад в реализацию методологии, предложенной в данной диссертации, принадлежит кафедре системного программирования СПбГУ и коллективу компании "ЛАНИТ-ТЕРКОМ". Без их самоотверженной работы автору вряд ли удалось бы превратить исходные идеи в успешное промышленное средство реинжиниринга. При подготовке текста диссертации важные советы и замечания дали А. А. Терехов, В. В. Оносовский, Д. Ю. Булычев, Т. А. Попова, А. Е. Тиунова.

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

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

ЗАКЛЮЧЕНИЕ

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

1. Создана концепция и методология модернизации устаревших приложений.

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

3. Под научным руководством соискателя реализована система RescueWare, накоплен успешный опыт ее практического использования.

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

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

6. Разработана оригинальная система преобразования монолитных приложений в многокомпонентные.

1. Bohml966. C. Bohm, G. Jacopini "Flow Diagrams, Turing Machines and Languages With Only Two Formation Rules", Communications of the ACM, Vol. 9, No. 5, May 1966. P. 366-371.

2. Breuerl991. P. T. Breuer, K. Lano "Creating Specifications from Code: Reverse-engineering Techniques", Journal of Software Maintenance: Research and Practice, Vol.3, 1991. P. 145-162.

3. ClaBenl997. I. ClaBen, K. Hennig, I. Mohr, M. Schulz "CUI to GUI Migration: Static Analysis of Character-Based Panels", In Proceedings of the 1st Euromicro Working Conference on Software Maintenance and Reengineering, Berlin, 1997. P.144-149.

4. Erlikh2002a. L. Erlikh "Integrating Legacy Systems Using Web Services", eAI Journal, August 2002, P. 12-17.

5. Erlikhl998. L. Erlikh, M. Ferris "Business-rule extraction from Cobol to Java", Java Pro. June/July, 1998. P. 54-63.

6. Erlikh.2001. L. Erlikh, L. Goldbaum "EAI's Missing Link: Legacy Integration", eAI Journal, April 2001, P. 12-16.

7. Erlikh2002b. L. Erlikh, M. Oara, M. Bulyonkov, A. N. Terekhov, V. Wadhwa "Method and system for recreating a user interface of an existing application text based user interface into a graphical user interface", February 2002. U.S. patent No. 6,346,953.

8. McCarthy1995. J. McCarthy "Dynamics of Software Development", Microsoft Press, 1995, 184 pp.

9. Miller1997. H. W. Miller "Reengineering Legacy Software Systems", Digital Press, 1997, 280 pp.

10. Paulson2000. L. D. Paulson "Making Legacy Assets Work in an Internet World", IT Professional, Vol. 2, No. 3, May/June 2000. P. 10-15.

11. Polakl995. 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.

12. Ransom 1998. J. Ransom, I. Sommerville, I. Warren "A Method for Assessing Legacy Systems for Evolution", In Proceedings of the 2nd Euroniicro Conference on Software Maintenance and Reengineering, 1998. P. 128-134.

13. Roberts2000. L. G. Roberts "Beyond Moore's Law: Internet Growth Trends", Computer, Vol. 33, No. 1, January 2000. P. 117-119.

14. Sellinkl999. A. Sellink, H. M. Sneed, C. Verhoef "Restructuring of COBOL/CICS Legacy Systems", In Proceedings of the Conference on Software Maintenance and Reengineering, Amsterdam, The Netherlands, 1999. P. 72-82.

15. Tip 1995. F. Tip "A survey of program slicing techniques", Journal of Programming Languages, No. 3, 1995. P. 121-189

16. Waters 1988. R. C. Waters "Program Translation via Abstraction and Reimplementa-tion", IEEE Transactions on Software Engineering, Vol. SE-14, No. 8, August 1988. P.1207-1228.

17. Wiggertsl997. T. Wiggerts, H. Bosma, E. Fielt "Scenarios for the Identification of Objects in Legacy Systems", In Proceedings of the 4th Working Conference on Reverse Engineering, 1997. P. 24-32.

18. Ершов 1975. А. П. Ершов "Проектные характеристики многоязыковой системы программирования", Кибернетика, №4, 1975. С. 11-27

19. Ершов1982. А.П.Ершов "Программирование вторая грамотность", Квант, 1982. № 2.

20. Захаров 1978. JI. А. Захаров, С. Б. Покровский, Г. Г. Степанов, С. В. Тен "Многоязыковая транслирующая система", Новосибирск, 1978.

21. Терехов1999. А.Н. Терехов, J1.A. Эрлих, А.А. Терехов "Перспективы реинжиниринга", Компьютер-Пресс, № 11, 1999.

22. Эрлих2000. J1.A. Эрлих "Модернизация старых программ как ключевой фактор электронной коммерции", в сб. "Автоматизированный реинжиниринг программ", СПб.: Издательство С.-Петербургского университета, 2000. С. 20-42.1. СПИСОК ИЛЛЮСТРАЦИЙ

23. Рис. 1. Сближение технологии и бизнеса.7

24. Рис. 2. Спектр подходов к обновлению старых комплексов.19

25. Рис. 3. Извлечение знаний в RescueWare.37

26. Рис. 4. Среды э-коммерческой интеграции компонентов в RescueWare.39

27. Рис. 6. Компонентизация старых комплексов — крупнозернистые компонентыи EAI.65

28. Рис. 7. Общая схема работ по преобразованию устаревших приложений.79