5-software_engineering_maintenance (1133545), страница 8
Текст из файла (страница 8)
Обратный инжинирингявляется пассивным, предполагая отсутствие деятельности по изменению или созданию новогопрограммного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаютсямодели вызовов (call graphs) и потоков управления (control flow graphs) на основе исходного кодасистемы. Один из типов обратного инжиниринга – создание новой документации на существующуюсистему (redocumentation). Другой из распространенных типов – восстановление дизайна системы(design recovery).К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы порефакторингу (см. работы Мартина Фаулера, впервые систематизировавшего и описавшегорефакторинг). Рефакторинг – трансформация программного обеспечения, в процессе которойпрограммная система реорганизуется (не переписываясь) с целью улучшения структуры, безизменения поведения. Сохранение “формы” (платформы, архитектурных и технологическихрешений) существующей программной системы позволяет рассматривать рефакторинг как один извариантов обратного инжиниринга.* для обеих тем – 4.2 и 4.3 возможно применение слова реконструкция, в зависимости от контекста,означающее как полную перестройку или воссоздание чего-либо, идентичного по определеннымхарактеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/илидоступным внешним признакам, где восстановление может подразумевать опять -таки создание нового образцаили представления об оригинальной сущности.В принципе, возможно объединение тем данной секции, включая реинжиниринг и обратныйинжиниринг, в общую тему 4.1 “Reverse and Re-engineering” данной области знаний“Сопровождение”, с дальнейшей детализаций в виде “под-тем” 4.1.x.
Такой подход соответствуетструктуре SWEBOK. При этом, соответствующая структура может быть организована, например,следующим образом:4.1.1 Формирование представления об эксплуатируемой/сопровождаемой системе:включает восстановление, в первую очередь, бизнес- и функциональных требований ксистеме;4.1.2 Восстановление детального дизайна системы: включает идентификацию всехкомпонентов системы и создание модели вызовов и других связей между компонентами;4.1.3 Рефакторинг: как возможный процесс структурных изменений, вносимых в систему, вчастности для улучшения возможностей по ее дальнейшему сопровождению (включаямодификацию, связанную с расширением функциональности);4.1.4 Переработка системы: создание нового релиза/версии системы в той же форме(например, с использованием той же технологической платформы), что и текущая(эксплуатируемая) версия;4.1.5 Создание новой системы: рассматривает текущую версию и систему в целом, какустаревшую – legacy.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru19.