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

Статические и динамические модели описывают логическую реализацию системы, отражают логический мир программного приложения.

Модели реализации – обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещение компонентов в аппаратных узлах.

Основной задачей логического проектирования при объектном подходе, является разработка классов для реализации объектов, полученных при объектной декомпозиции, что предполагает полное описание полей и методов каждого класса.

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

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

Компонент – это физический фрагмент реализации системы, который заключает в себе программный код (исходный, двоичный, исполняемый), сценарные описания или наборы команд операционной системы (командные файлы).

В UML компонент – это физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов. Компоненты имеют только операции, которые доступны через их интерфейсы.

Компонент является базисным строительным блоком физического представления ПО, в то время, как класс – базисный строительный блок логического представления ПО.

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

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

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

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

 

Компонент К₂, который реализует интерфейс, подключается к нему отношением реализации. Компонент К₁, который получает доступ к услугам другого компонента через интерфейс, по – прежнему подключается к интерфейсу отношением зависимости.

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

Повторное использование компонентов – магистральный путь развития программного инструментария, так как приводит к более надежному и дешевому коду. Основная цель программных компонентов – допускать сборку системы из двоичных заменяемых частей. Они должны обеспечить начальное создание системы из компонентов, а затем ее развитие – добавление новых компонентов и замену старых без перестройки системы в целом. Ключ к воплощению такой возможности - интерфейсы. После того, как интерфейс определен, к выполняемой системе можно подключить любой компонент, который удовлетворяет ему или обеспечивает этот интерфейс. Механизм замены компонента другим оговорен современными компонентными моделями (СОМ, СОМ+, CORBA, JavaBeans), требующими незначительных преобразований или предоставляющими утилиты, которые автоматизируют механизм.

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

- периода компиляции (среди текстовых компонентов);

- периода сборки, линковки (среди объектных двоичных компонентов); - периода выполнения (среди машинных компонентов).

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

Моделирование перечисленных компонентов и отношений между ними – важная часть управления конфигурацией системы.

Диаграммы размещения

Это вторая разновидность диаграмм реализации UML, моделирующих физические аспекты объектно-ориентированных систем. Диаграмма размещения показывает конфигурацию обрабатываемых узлов в период работы системы, а также компоненты, “живущие” в этих узлах. Диаграммы размещения могут включать компоненты, содержать пакеты или подсистемы, используемые для группировки элементов модели в крупные фрагменты, и даже содержать объекты.

Узел – это физический элемент, который существует в период работы системы и представляет собой компьютерный ресурс, имеющий память, а возможно, и способность обработки.

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

Изобразим типовую трехуровневую систему в виде диаграммы размещения (рис. 8.5)

Рис. 8.5 Моделирование размещения компонентов

Уровень базы данных реализован экземпляром А, узла Сервер Данных. Уровень бизнес – логики представлен экземпляром В, узла Бизнес Сервер. Уровень графического интерфейса пользователя образован экземпляром С, узла Клиент.

Иногда полезно определить физическое распределение компонентов по процессорам и другим устройствам, например, в случае распределенных систем.

⇐ Предыдущая23242526272829303132Следующая ⇒

Поделиться: