Интерфейсы, взаимодействие и изменение программ и данных

8.4. Методы изменения (эволюции) компонентов и ПС

Активное использование готовых ПС проводится при создании и сопровождении системы. При этом возникают разного рода ошибки, которые требуют внесения изменений в систему после того, как ошибка обнаружена или возникла необходимость в изменении или улучшении некоторых характеристик системы [8.15, 16-22] .

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

Типичные причины внесения изменений это:

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

Как утверждают эксперты, процесс внесения изменений в эксплуатируемую систему достаточно дорогой, оценки его стоимости достигают от 60 до 80 % от общей стоимости разработки системы.

К видам сопровождения относятся:

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

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

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

В общем, процесс изменения (эволюции) ПС проводятся путем:

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

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

Например, широкий круг специалистов затронула проблема изменения формата даты в 2000 году. Для систематической переделки функционирующих программ к новым возможностям ОС, языков и платформ современных компьютеров и т. п. используются современный аутсорсинг (Индия, Россия, Украина и др. ).

Внесение изменений в ПО можно рассматривать как эволюционный путь его развития. Эволюция ПО осуществляетсявнешними методами обработки компонентов в распределенной среде и внутренними методами, как изменение компонентов (СОМ), интерфейсов (Int) и/или систем. К внутренним методам эволюции отнесены методы реинженерии, рефакторинга и реверсной инженерии (рис. 8.10).

Эти методы обеспечивают разноплановое изменение программ или систем.

К ним относятся корректировка спецификаций, документации и программного кода в соответствии с требованиями на изменения [8.15-8.20].

увеличить изображение
Рис. 8.10. Схема методов эволюции компонентов ПС

Суть этих методов состоит в следующем:

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

8.4.1. Реинженерия программных систем

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

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

С технической точки зрения реинженерия - это решение проблемы эволюции системы путем изменения ее архитектуры в измененной среде, в которой компоненты размещаются на разных компьютерах. Причиной эволюции может быть изменение ЯП системы, например, Fortran, Сobol и др. с переходом на современные объектно-ориентированные языки, такие, как Java или C++.

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

По сравнению с более радикальными подходами к совершенствованию систем реинженерия имеет следующие преимущества.

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

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

Основное различие между реинженерией и новой разработкой системы состоит в том, что написание системной спецификации начинается не с "нуля", а с рассмотрения возможностей старой наследуемой системы.

К основным этапам процесса реинженерии относятся:

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

Причинами, требующими преобразование исходного кода программ в другой язык, могут быть:

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

К операциям реинженерии относятся:

• именование компонентов и их идентификация;
• расширение функций существующей реализации компонентов;
• перевод языка компонента в новый современный ЯП;
• реструктуризация структуры компонента;
• модификация описания компонента и его данных.

8.4.2. Рефакторинг компонентов

Рефакторинг получил развитие в объектно-ориентированном программировании в связи с широким применением интерфейсов, шаблонов проектирования и методов улучшения кода [8.5]. Разработаны библиотеки типовых трансформаций искомых объектов (классов), которые улучшают те или иные характеристики ПС.

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

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

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

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

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

Операции над компонентами удовлетворяют условиям:

• объект, полученный в результате рефакторинга, - это компонент с соответствующими свойствами, характеристиками и типичной структурой;
• операция не изменяет функциональность компонента и новый компонент может применяться в ранее построенных компонентных системах;
• перестройка компонентов, а иногда и перепрограммирования проводится в процессе реверсной инженерии [8.15, 8.18].

8.4.3. Реверсная инженерия

Методы реверсной инженерии, которые разработаны в среде объектно-ориентированного программирования, базируются на выполнении базовых операций визуализации (visual) и измерения метрик (metric) ПС в рамках модели, которая предлагает следующие цели:

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

Этот подход ориентирован на индустриальные системы в миллион строк кода с использованием метрических оценок характеристик системы. Он разрешает генерацию тестов для проверки кодов, а также проведение метрического анализа системы для получения фактических значений внутренних и внешних характеристик системы [8.20].

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

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

Таким образком, рассмотрены базовые понятия интерфейса, подходы к обеспечению интерфейса языков программирования и взаимодействия разноязыковых программ и данных. Определены общие проблемы неоднородности ЯП, платформ компьютеров и сред, влияющие на выполнение связей между разноязыковыми программами, сформулированы пути их решения. Изложены стандартные решения ISO/IEC 11404-1996 по обеспечению независимых от ЯП типов данных, стандарты преобразования форматов данных и эволюция программных систем.

Контрольные вопросы и задания

1. Определите цели и задачи интерфейса в программной инженерии.
2. Назовите системы, которые основываются на интерфейсах и обеспечивают преобразование данных.
3. Охарактеризуйте кратко современные распределенные системы (например, CORBA).
4. Назовите методы вызова компонентов в распределенных средах.
5. Определите формальную схему взаимодействия программ.
6. Определите основные задачи интерфейса ЯП.
7. Назовите современные подходы к взаимодействию разноязыковых программ.
8. Определите проблемы преобразования форматов данных.
9. Какие методы преобразования данных БД существуют?Определите цели и задачи изменения ПС при сопровождении.
10. Дайте краткую характеристику проблем, возникающих при сопровождении системы.
11. Определите основные задачи реинженерии ПС.
12. Чем отличается рефакторинг компонентов от реинженерии?
13. Определите основные операции реверсной инженерии ПС.