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

Рефакторинг получил развитие в объектно–ориентированном программировании [2] в связи с применением шаблонов проектирования, методов улучшения кода и структуры объектно–ориентированных программ. Были разработаны целые библиотеки типичных трансформаций искомых объектов (классов), которые улучшают те или другие характеристики. Он вошел в компонентное программирование и базируется на типичной структуре, модели компонента и ориентирован на изменении не только компонентов, а и их интерфейсов.

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

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

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

– добавление новой реализации для существующего и нового интерфейса;

– замена существующей реализации новой с эквивалентной функциональностью;

– добавление нового интерфейса (при условии наличия соответствующей реализации);

– расширение существующего интерфейса;

– расширение интерфейса для новых системных сервисов в компонентной среде.

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

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

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

– объект, полученный в результате рефакторинга является компонентом с соответствующими свойствами, характеристиками и типичной структурой;

– операция не изменяют функциональность, то есть новый компонент может примениться в раннее построенных компонентных системах;

– перестройки или переделки компонентов, а иногда и перепрограммирования в случае реверсной инженерии [4, 5].

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

Методы реверсной инженерии разработаны в среде объектно–ориентированного программирования [1]. Они базируется на выполнении базовых операций визуализации (visual) и измерения метрик (metric) программных систем в рамках модели, которая предлагает следующие цели:

– обеспечение высокого качества системы и переосвидетельствование ее размера, сложности и структуры;

– поиск иерархии классов и атритутов программных объектов с целью наследования их в ядре системы;

– идентификация классов объектов с определением размера и /или сложности всех классов системы;

– поиск патернов, их идентификация, а также фиксация их места и роли в структуре системы.

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

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

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

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

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

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

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

1. Определите цели и задачи метода интеграции в программной инженерии.

2. Назовите системы, которые поддерживают процессы интеграции и преобразования данных.

3. Охарактеризуйте кратко современные системы взаимосвязи объектов – COM, CORBA, JAVA и др.

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

5. Какую роль выполняет брокер объектных запросов

6. Определите проблему преобразования данных в ЯП.

7. Какие требуется провести преобразования передаваемых по сети данных от объекта JAVA в к объекту в С++ и обратною

8. Определите проблемы преобразования данных, связанные с заменой одной БД на другую.

9. Какие методы переноса данных существуют?

10. Определите цели и задачи изменения ПС при проведении сопровождения.

11. Какие выполняются работы при сопровождении, когда вносятся изменения?

12. Дайте краткую характеристику проблем, возникающих при сопровождении системы.

13. Определите основные задачи реинженерии ПО.

14. Определите основные операции рефакторинга компонентов.

15. Определите основные операции реинженерии программных систем.

Литература к теме 8.

1. Open Software Foundation. Inroduce to Open Software Foundation. Disributed Computed Environments.– Englewood Cliffs: Prentice Hall, 1993.– 437p.

2. Corbin J. The art of Distributed Application. Programming Techn. For Remote Procedure Calls.– Berlin: Springer Verlag, 1992.– 305p.

3. Роджерсон Д. Основы СОМ. Руск..пер.– Microsoft Press.– 361c.

4. CORBA. The Common Object Request Broker: Architecture and Specification. Revision 2.0. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc.–1995.–621 p.

5. Монсон–Хейфел Р. Enterprise JavaBeans. – СПб: Символ–Плюс, 2002. – 672 с.

6. Барлет Н., Лесли А., Симкин С. Программирование на JAVA. Путеводитель.– Киев.–1996.– 736с.

7. Иванников В.П., Дышлевый К.В., Мажелей С.Г., Содовская Д.Б., Шебуняев А.Б.Распределенные объектно–ориентированные среды.– Москва // РАН.ИСП. Труды ИСП,.–2000.– с.84–100.

8. Гост 30664 (ИСО/МЭК 11404:1996). Информа­ционные технологии. Языки программирования, их среда и системный интер­фейс. Зависимые от языков типы данных/ Межгосударственный стандарт.–Межгосударственный совет по стандартизации, метрологии и сертификации, 2000. – 112 с.

9. Джордан Д. Обработка объектных бах данных в С++. Программирование по стандарту ODMG: Пер.с англ. – М.: Издательский дом “Вильямс”, 2001. – 384 с.

10. Дунаев С. Б. Доступ к базам данных и техника работы в сети. – М.: Диалог–Мифи, 1999. – 416 с.

11. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510с.

12. Лаврищева Е.М., Грищенко В.М. Сборочное программирование .–Киев.– Наукова думка.– 1991. –213с.

13. Лаврищева Е.М. Парадигма интеграции в программной инженерии// Программирование, 2000.– №1–2 (Труды второй междун.науч..конф. УкПрог–2000, 23–26мая 2000г. –Киев).– с.351–360.

14. Lanza M., Ducasse S. Polimetric Views –A lightweight Visual Approach to Reverse Engineering //IEEET Transaction on Software Engineering.– 2003.– Sept., №3 (ISSN 0098–5589).– P.782–796.

15. Фаулер М. Рефакторинг: улучшение соответствующего кода. – СПб.: Символ–Плюс, 2003. – 432 с.

16. Пантелеймонов А.А. Аспекты реинженерии приложений с графическим интерфейсом пользователя//Проблемы программирования .–2001.–№1–2.– С.53–62.

17. Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии «Знание».–2001. –269с.

18. Соммервилл И. Инженерия программного обеспечения.– Изд. Дом «Вильямс», Москва

19. Игнатенко П.П., Неумоин В.Н., Бистров В.М. Об обеспеченни эффективного реинжинеринга прикладних програмних систем // Пробл. программирования. – 2001. – №1–2. – с. 42–52.

20. Гласс Г., Нуазо Р. Сопровождение программного обеспечения. Пер.с анг. // Под ред. Ю.А.Чернышова.– М.:.Мир.– 1983.–256 с.

Тема 9