вернуть S. Хуже того, ошибка в одной из таких функций внутри D мо-
жет спровоцировать появление ошибок в F и S.
Для избегания подобной ситуации F должен внутри себя создать абстрактный класс DA, обеспечивающий основные операции измене-
ния данных (т.е. операции CRUD [33]). Затем для поддержки конкрет-
ной системы управления базами данных (СУБД) авторы F должны предложить архитектору системы S реализовать основные методы
CRUD для конкретной СУБД D. В этом случае архитектор системы S
будет иметь возможность управлять зависимостью системы S от D и в случае возникновения ошибки – самостоятельно её исправить.
Принцип инверсии зависимостей также утверждает, что любую за-
висимость можно инвертировать, создав дополнительный уровень аб-
стракции [25]. Решение проблемы, представленной выше, как раз и свя-
зано с добавлением такого уровня: когда зависимость F от D была за-
менена парой зависимостей F от D` и D от D`.
3.3. Программные компоненты и принципы их организации
Компонентом называется обособленная логически связанная часть ИС, имеющая чёткие архитектурные границы. В большинстве языков программирования отсутствуют языки конструкций, прямо отражаю-
щие понятие компонентов. Компонентом можно назвать совокупность программных сущностей, предназначенную для решения одной бизнес-
задачи.
Компонентами могут являться как программы целиком, так и про-
граммные модули, библиотеки классов, пакеты Java и т.д. Для описания взаимосвязи программных компонентов используется диаграмма ком-
понентов UML.
37
3.3.1. Диаграмма компонентов
Диаграмма компонентов, входящая в состав универсального языка разметки UML [34], используется для описания компонентов системы,
а также для описания механизмов их взаимодействия.
Компонент на диаграмме отображается структурой, изображённой на рис. 5. Компоненты связываются между собой посредством интер-
фейсов. Предоставляемый компонентом интерфейс обозначается сим-
волом окружности на линии («леденец»). Интерфейс, необходимый компоненту для работы, обозначается полукругом на линии («полуме-
сяц»). Диаграмма компонентов может быть расширена символом зави-
симости UML. В этом случае можно считать, что «леденец» порождает экземпляр интерфейса, «полумесяц» в процессе своей работы изменяет созданный экземпляр, «зависимость» – говорит об использовании эк-
земпляра в режиме только чтения.
Общая диаграмма компонентов приведена на рис. 6.
Рисунок 5 – Элементы диаграммы компонентов
Рисунок 6 – Пример диаграммы компонентов
38
Для описания взаимосвязи компонентов достаточно вышеприве-
дённых изображений. Однако UML диаграмма компонентов включает в себя большее число возможностей, таких, например, как поддержка портов, группировка компонентов и пр.
3.3.2. Принципы взаимосвязи компонентов
Всякий класс можно отнести к компоненту. Однако решение, к ка-
кому именно компоненту, должно приниматься в соответствии с заре-
комендовавшими себя принципами разработки программного обеспе-
чения. Подобные решения носят своеобразный характер и принимаются исходя из контекста.
Принципы, определяющие взаимосвязь компонентов, представле-
ны ниже.
1.REP: Reuse/Release Equivalence Principle – принцип эквивалент-
ности повторного использования и выпусков.
2.CCP: Common Closure Principle – принцип согласованного изме-
нения.
3.CRP: Common Reuse Principle – принцип совместного повторного
использования.
Все 3 принципа связаны между собой. Связь можно представить в виде диаграммы противоречий (описана в разделе 3.3.6).
Если разрабатываемая ИС находится близко к REP, то она не удов-
летворяет CRP, CCP, если в середине треугольника, то не удовлетворя-
ет в полной мере всем трём признакам (рис. 7).
3.3.3. Принцип эквивалентности повторного использования и выпусков
Данный принцип формулируется следующим образом: единица повторного использования есть единица выпуска.
39
REP определяет размер компонентов. Каждый компонент может быть выпущен обособленно от других компонентов. Можно делать вы-
пуски отдельных узлов ИС. Любой повторно использующийся объект кода может быть представлен в виде отдельного компонента. Таким об-
разом, подход позволяет реализовать выпуск микрорелизов.
Любой метод, который используется повторно, выкладывается в виде отдельных компонентов.
Например, сайт использует в качестве компонента внешний ресурс для загрузки изображений. После обновления у пользователя сайта бы-
ла утечка памяти. В том случае, если бы ИС соответствовала REP,
можно было бы изменить 1 файл, а несоблюдение принципа приводит к сборке всего сайта, что в свою очередь требует проведения полного регрессионного тестирования [34].
Данный принцип означает, что классы и модули, составляющие компонент, должны принадлежать связной группе. Компонент не мо-
жет просто включать случайную совокупность классов и модулей; не-
обходимы совместные цель, тема.
Однако классы и модули, объединяемые в компонент, должны вы-
пускаться вместе. Объединение их в один выпуск и включение в общую документацию с описанием этой версии должны иметь смысл для авто-
ра и пользователей.
В этом случае необходимо подробно и точно описать, что именно объединяет классы и модули в один компонент.
3.3.4. Принцип согласованного изменения
Формулируется принцип согласованного изменения следующим образом: в один компонент должны включаться классы, которые пре-
терпевают изменения по одним причинам и в одно время; в разные
40