Реинжиниринг

Обратное проектирование

История сопровождаемого программного продукта может быть очень непростой. Многие существующие приложения часто оказываются снабжены скудной или противоречивой документацией. Первым шагом в организации рациональных работ по сопровождению таких приложений должно быть создание подробной согласованной документации. Для этого часто требуется восстановление архи­тектуры по исходному коду – обратное проектирование (reverse engineering). Существует несколько программных средств, помогающих выполнить эту задачу. Например, пакеты Rational Rose (Rational Corporation) и Together (Object Inter­national) позволяют создавать модели объектов из исходного кода на C++ и Java. Получающиеся в результате диаграммы можно использовать для анализа хода мыслей разработчика. Из-за неоднозначности трактовки диаграмм на UML и меха­ничности процесса обращения обратное проектирование не позволяет полностью понять намерения разработчика. Когда разработчик рисует прямоугольники и связи UML, их геометрическое размещение (например, группировка) несет смысловую нагрузку, воспринимаемую только людьми.

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

 

В 1980 году в книге Хаммера и Чампи о реинжиниринге бизнес-процесса (BPR – Business Process Reengineering) компаниям предлагалось заново взгля­нуть на процесс производства ценностей для потребителей, после чего спроек­тировать его заново. Хаммер и Чампи основное внимание уделяли процессу как целому, а не отдельным его частям. Процесс начинается с входных данных, на­пример заказов, заканчивается окончательной отгрузкой товаров или предостав­лением услуг и включает все способствующие достижению цели элементы, такие как поддержка программ и вклад сотрудников. Реинжиниринг заставляет взгля­нуть на требования к программным приложениям как на часть требований к пред­приятию (компании, организации и т. п.) в целом. Получающиеся приложения иногда называются корпоративными приложениями (enterprise application), хотя обсуждаемая концепция используется и вне контекста реинжиниринга бизнес-процесса. Реинжиниринг обычно заставляет ответить на вопрос о том, как долж­ны работать существующие приложения, а не о том, как они работают. Фактиче­ски, при реинжиниринге к бизнес-процессу применяются концепции системной разработки.

Реинжиниринг относят к сопровождению, потому что он требует переплани­рования приложений. Сравнение экспансивного развития с реинжинирингом на примере моста приводится на рис. 2.5. В первом случае мост укрепляется, а во втором – перестраивается для того, чтобы отвечать возросшим требованиям.

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

Рис. 2.5. Сопровождение с реинжинирингом и без него