Модели реализации объектно-ориентированных

Программных систем в UML

Компонентные диаграммы

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

Интерфейс — очень важная часть понятия «компонент». Графически компонент изображается как прямоугольник с вкладками, обычно включающий имя (рис. 17).

Рис.17.Обозначение компонента

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

Рис..18. Классы в компоненте

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

Интерфейсы

Интерфейс — список операций, которые определяют услуги класса или компонента. С помощью интерфейсов компоненты стыкуются друг с другом, объединяясь в систему. Все операции интерфейса открыты и видимы клиенту (в противном случае они потеряли бы всякий смысл). Итак, операции интерфейса только именуют предлагаемые услуги, не более того. Очень важна взаимосвязь между компонентом и интерфейсом. Возможны два способа отображения взаимосвязи между компонентом и его интерфейсами. В первом, свернутом способе, как показано на рис. 19, интерфейс изображается в форме пиктограммы. Компонент Образ.java, который реализует интерфейс, соединяется со значком интерфейса (кружком). Наблюдатель Образа простой линией. Компонент РыцарьПечальногоОбраза.java, который использует интерфейс, связан с ним отношением зависимости.

Рис. 19. Представление интерфейса в форме пиктограммы

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

Рис.20 Развёрнутая форма представления интерфейса.

Компоновка системы

За последние полвека разработчики аппаратуры прошли путь от компьютеров размером с комнату до крошечных «ноутбуков», обеспечивших возросшие функциональные возможности. За те же полвека разработчики программного обеспечения прошли путь от больших систем на Ассемблере и Фортране до еще больших систем на С++ и.jаvа, но программный инструментарий развивается медленнее, чем аппаратный инструментарий. В чем главный секрет аппаратчиков? Этот секрет — компоненты. Разработчик аппаратуры создает систему из готовых аппаратных компонентов (микросхем), выполняющих определенные функции и предоставляющих набор услуг через ясные интерфейсы, Задача конструкторов упрощается за счет повторного использования результатов, полученных другими. Повторное использование — магистральный путь развития программного инструментария. Создание нового ПО из существующих, работоспособных программных компонентов приводит к более надежному и дешевому коду. При этом сроки разработки существенно сокращаются. Основная цель программных компонентов — допускать сборку системы из двоичных заменяемых частей. Они должны обеспечить начальное создание системы из компонентов, а затем и ее развитие — добавление новых компонентов и замену некоторых старых компонентов без перестройки системы в целом. Ключ к воплощению такой возможности – интерфейсы. После того как интерфейс определён, к выполняемой системе можно подключить любой компонент, который удовлетворяет ему или обеспечивает этот интерфейс. Для расширения системы производятся компоненты, которые обеспечивают дополнительные услуги через новые интерфейсы. Такой подход основывается на особенностях перечисленных в табл. 2

Таблица 2.

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

Разновидности компонентов

Мир современных компонентов достаточно широк и разнообразен. В языке UML для обозначения новых разновидностей компонентов используют механизм стереотипов. Стандартные стереотипы, предусмотренные в UML для компонентов, представлены в таблице 3

Таблица 3 -Разновидности компонентов

В языке UML неопределенны пиктограммы для перечисленных стереотипов, применяемые на практике пиктограммы компонентов показаны ниже: