Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

Архитектурный рефакторинг. Архитектурные паттерны

Когда нужен архитектурный рефакторинг

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

  • 1. Преобразования, обусловленные функциональными изменениями ПС. Желательно, чтобы внедрение новой функциональности не затронуло существующую логику системы. Также желательно, чтобы сложность внедрения новой функциональности в существующую систему не превышала существенным образом сложность реализации этой функциональности в рамках нового проекта. Изменение существующей архитектуры - хороший шаг на пути внедрения новой функциональности, облегчающий и дальнейшую эволюцию системы.
  • 2. Смена платформы ПС (как аппаратной, так и общего программного обеспечения, в частности операционной системы) должна минимально затрагивать существующий код. Желательно ограничиться изменениями только в узкой, платформенно-зависимой прослойке системы. Выделение такой прослойки - архитектурная задача. Ее решение всегда сопряжено с необходимостью изменения архитектуры.
  • 3. Обновление технологии разработки программного продукта, связанное, например, с переходом на компонентное программирование, внедрением комплексной среды коллективной разработки с возможностями гибкого, формального и смешанного планирования и ведения отчетности, доступными на одной платформе, например IBM Rational Team Concert.
  • 4. Преобразования, связанные с реорганизацией компании, ведущей разработку. Примером такой реорганизации может стать аутсорсинг. Решение об использовании аутсорсинга - типичный шаг по оптимизации производства. К сожалению, этот шаг зачастую затрудняется проблемой выделения и передачи компонентов для внешней разработки. Изменение архитектуры программной системы способно облегчить решение этой задачи.

При описании методов рефакторинга принято использовать частично формализованный формат - шаблон или паттерн [32, 38]. Это повто-римая конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться [36]. «Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные. На наивысшем уровне существуют архитектурные шаблоны. Они охватывают собой архитектуру всей системы.

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

Например, в [33] паттерн имеет следующую структуру:

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

Известно, что рефакторинг объектно ориентированного кода зарекомендовал себя как эффективный способ решения задач эволюции и сопровождения программ. Однако, и это отмечается в статьях М. Ксензова [14, 15], опубликованных в 2004 г., практически не существует исследований, освещающих рефакторинг на более высоком уровне абстракции - уровне архитектуры ПО. Ситуация мало изменилась и к настоящему времени. Поэтому вызывает интерес, возможен ли перенос данной методологии на более высокий уровень абстракции с целью получения аналогичной методики систематического изменения архитектуры ПО.

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

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы