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

Архитектурный рефакторинг для повышения производительности многослойных программных систем

Возможный подход к созданию программных систем

В свое время М. Фаулер высказал идею рефакторинга БД, однако об ахитектурном рефакторинге программных систем речи не было. Надо сказать, и в настоящее время вопросам архитектурного рефакторинга посвящено незначительное количество работ. В то же время эволюция сложных программных систем требует от разработчика повышенного внимания к выбору архитектуры. Практически всегда во время разработки появляются новые требования со стороны заказчика, и приходиться пересматривать первоначальную архитектуру. Выделяют следующие фазы архитектурного рефакторинга: 1) «раскопки» архитекту-

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

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

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

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

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

м = {mij | / = 1, 2,..., N, 7 = 1,2,..., л,.},

n (7 7)

M = JM„ м = к, где N - количество бизнес-процессов; К- количество модулей в программной системе; / - номер бизнес-процесса; j - номер модуля, реализующего у-функцию 7-го бизнес-процесса; /7, - количество функций, реализуемых 7-м бизнес-процессом; Mj - подмножество модулей, автоматизирующих 7-Й бизнес-процесс bj е В.

В общем случае справедливо соотношение

N

(7.8)

П м,. ф 0.

Каждый модуль Шу можно представить следующими параметрами спецификации:

(7.9)

Pij ~ {Name, Ijj, Ojj, A-},

где Name - имя модуля ту, Ц - параметры входного интерфейса модуля ту Oij - параметры выходного интерфейса модуля т,у Ау - абстракция алгоритма, реализуемого модулем ту.

Заметим, что абстракция через спецификацию позволяет абстрагироваться от алгоритма, описанного в теле модуля, до уровня знания лишь того, что данный модуль должен в итоге реализовать. Существует отображение вида О.В —> М, которое определяет подмножества модулей, автоматизирующих функции конкретных бизнес-процессов. Таким образом, существуют отображения О, : bi —> Mi М, i = 1, 2,..., N. При этом возможны непустые пересечения:

(7.10)

Это свидетельствует о возможном дублировании некоторых функций бизнес-процессов в автоматизируемых их модулях ПС. Однако возможны ситуации, когда для некоторого отображения О,- М < Ь,, что говорит том, что ПС реализует не все функции бизнес-процесса 6,. Но даже если в этом плане нет претензий к разработанной программной системе, как отмечено выше, часто архитектура ПС не только предварительно не разрабатывается, но и недостаточно (или совсем) не документируется. Отсюда в интересах дальнейшей разработки системы или ее сопровождения возникает проблема «раскопки» архитектуры, как ее часто называют в литературе [2, 3].

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

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