Известно, что основной задачей первых трех десятилетий компьютерной эры являлось развитие аппаратных

Компоненты 
По своей сути компонент является физическим фрагментом реализации системы, который заключает в себе программный 
код (исходный, двоичный, исполняемый), сценарные описания или наборы команд операционной системз (имеются в виду 
командные файлы). Язык UML дает следующее определение. 
Компонент — 
физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает 
реализацию этого набора интерфейсов. 
Интерфейс — очень важная часть понятия «компонент», его мы обсудим в следующем подразделе. Графически компонент 
изображается как прямоугольник с вкладками, обычно включающий имя (рис. 13.1). 
Рис. 13.1. 
Обозначение компонента 
Компонент — базисный строительный блок физического представления ПО, поэтому интересно сравнить его с базисным 
строительным блоком логического представления ПО — классом. 
Сходные характеристики компонента и класса: 

наличие имени; 

реализация набора интерфейсов; 

участие в отношениях зависимости; 

возможность быть вложенным; 

наличие экземпляров (экземпляры компонентов можно использовать только в диаграммах размещения). 
Вы скажете — много общего. И тем не менее между компонентами и классами есть существенная разница, ее 
характеризует табл. 13.1. 
 
Таблица 13.1. 
Различия компонентов и классов 
№
Описание
1 
2
3
Классы — логические абстракции, компоненты — физические предметы, которые живут в мире битов. В 
частности, компоненты могут «жить» в физических узлах, а классы лишены такой возможности 
Компоненты являются физическими упаковками, контейнерами, инкапсулирующими в себе различные 
логические элементы. Они — элементы абстракций другого уровня 
Классы имеют свойства и операции. Компоненты имеют только операции, которые доступны через их 
интерфейсы
Рис. 
13.2. Классы в компоненте 
О чем говорят эти различия? Во-первых, класс не может «дышать» воздухом физического мира реализации. Ему нужен 
скафандр. Таким скафандром является компонент. 
Во-вторых, им не жить друг без друга — пустые скафандры никому не нужны. Причем в скафандре-компоненте может 
находиться несколько классов и коопераций. Итак, в скафандре — физической реализации — располагается набор логики. 
Как показано на рис. 13.2, с помощью отношения зависимости можно явно отобразить отношение между компонентом и 
классами, которые он реализует. Правда, чаще всего такие отношения не отображаются. Их удобно представлять в 
компонентной спецификации. 
В-третьих, класс — душа нараспашку (он может даже показать свои свойства). Компонент всегда застегнут на все 
пуговицы (правда, из него торчат интерфейсные разъемы операций). 
Теперь уместно перейти к обсуждению интерфейсов. 

жүктеу/скачать 1,76 Mb.

Достарыңызбен бөлісу: