2.3.4. Рефакторинг

Часто усовершенствование программы требует не просто изменения отдельных строк кода, а приложения гораздо больших усилий, не достигающих, однако, мас­штабов полного реинжиниринга. Иногда этот процесс называют рефакторингом (refactoring). Фаулер рассматривает пример проекта для магазина видео­фильмов – этот проект не слишком хорош, но вполне пригоден для конкретной простой задачи. Затем он показывает, как можно переделать проект под новые требования, например добавить возможность формирования новых типов отче­тов. Этот процесс включает экстракцию метода (то есть создание метода, заме­няющего имеющийся фрагмент кода).

2.3.5. Унаследованные приложения

Унаследованные системы (legacy systems) – это приложения, решающие сущест­вующие задачи. Иногда термин legacy трактуется как устаревшие и применяется к программам, которые не стоят того, чтобы их модифицировать.

Беннетт перечисляет возможные действия с унаследованными системами.

• Продолжать сопровождение;

• Прекратить сопровождение и:

• заменить на покупной продукт;

• заменить на собственный продукт, полученный обратным проектирова­нием или разработкой с нуля. Возможна поэтапная замена;

• присоединить к новому приложению. Сопровождение заморозить;

• инкапсулировать и использовать как сервер.

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

При инкапсуляции исходное приложение практически не изменяется. Новое приложение создается полностью независимо, а в процессе его выполнения вы­зывается функциональность унаследованного приложения. Это может осуществ­ляться как напрямую (метка ed), так и через обертку (метка ew). Обертка – это программное обеспечение, предоставляющее интерфейс для обращения клиен­тов к унаследованному приложению. В частности, обертка может сделать любое приложение внешне объектно-ориентированным.

Рис. 2.6. Использование унаследованных приложений

2.3.6. Обновление документации

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

2.4. Стандарт ieee 1219-1992

Стандарт IEEE 1219-1992 определяет процесс сопровождения программного обеспечения. Семь стадий процесса, описанные в этом стандарте, приблизитель­но соответствуют стадиям процесса разработки. Каждая стадия характеризуется шестью атрибутами (рис. 2.7). Значения этих атрибутов для каждой из семи ста­дий процесса сопровождения приведены в табл. 2.1 – табл. 2.4. Содержание стандарта IEEE 1219-1992 приводится ниже.

1. Определение задачи

1. Входные данные

2. Процесс

3. Контроль

4. Выходные данные

5. Факторы качества

6. Метрики

2. Анализ

1. Входные данные

2. Процесс

1. Анализ осуществимости

2. Подробный анализ

2.3-2.6. Контроль, Выходные данные, Факторы качества, Метрики

3. Проектирование

3.1-3.6. Входные данные, Процесс, Контроль, Выходные данные, Факторы качества, Метрики

4. Реализация

1. Входные данные

2. Процесс

4.2.1. Кодирование и тестирование

3. Анализ и обзор рисков

4. Проверка готовности к тестированию

4.3-4.6. Контроль, Выходные данные, Факторы качества, Метрики