Диаграммы реализации

1.

Диаграммы реализации
1

2.

Уровни представления модели
• Существует два уровня представления модели:
– логический уровень,
– физический уровень.
• Элементы логического представления, такие как классы,
ассоциации, состояния, сообщения, физически не
существуют.
• Рассмотренные ранее диаграммы отражали концептуальные
аспекты построения модели системы и относились к
логическому уровню представления.
• Для создания конкретной физической системы необходимо
некоторым образом реализовать все элементы логического
представления в конкретные материальные сущности. Для
описания таких реальных сущностей предназначен другой
аспект модельного представления, а именно физическое
представление модели.
• Например, алгоритм программы – это логическое
представление, а запись программы на языке
программирования и исполняемый файл программы – это
физическое представление программы.
2

3.

Физический уровень
• В языке UML для физического
представления моделей систем
используются диаграммы реализации
(implementation diagrams)
• Существует два вида диаграмм
реализации:
– диаграмма компонентов (component diagram)
– диаграмма развертывания (deployment
diagram)
• Обе диаграммы описывают статическую
структуру системы.
3

4.

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

5.

Использование диаграммы
компонентов
• Диаграмма компонентов разрабатывается для
разных целей:
– Описания структуры исходного кода
программной системы. Показываются файлы
исходного кода и содержащиеся в них
классы.
– Спецификации исполняемой версии.
Описываются файлы, которые должна
содержать поставляемая система.
– Разбиения системы на подсистемы.
– Представления физической схемы базы
5
данных (список таблиц базы данных).

6.

Компонент
• Компонент (component) служит для общего
обозначения элементов физического представления
модели.
• Компонент представляет собой некоторый файл с
исходным кодом классов, библиотеку, некоторый
исполняемый модуль.
• Компонент реализует некоторый набор
интерфейсов.
• Графическое изображение
6

7.

Реализация компонента
• Компонент может быть реализован с
помощью некоторого множества классов.
• На диаграмме классов мы объединяли
классы в пакеты. Обычно пакету на
физическом уровне соответствует
компонент.
• Для показа реализации компонента
используется либо отношение реализации
(Component Realization), либо класс
изображается внутри компонента, который
он реализует.
7

8.

Примеры реализации
8

9.

Зависимости
• Между компонентами могут существовать отношения
зависимости (dependency)
• Зависимость указывает, что изменение одного
компонента оказывает влияние или приводит к
изменению другого компонента.
• Зависимости могут отражать:
– связи модулей программы на этапе компиляции и
генерации объектного кода;
– наличие в независимом компоненте описаний классов,
которые используются в зависимом компоненте для
создания соответствующих объектов;
– использование одних компонентов другими
компонентами.
9

10.

Интерфейсы
• На диаграмме компонентов могут изображаться интерфейсы
(interface).
• Наличие интерфейсов у компонента означает, что данный
компонент реализует соответствующий набор интерфейсов.
• Интерфейс, реализуемый компонентом, называется
экспортируемым.
• Компонент предоставляет данный интерфейс в качестве
сервиса другим компонентам.
• Интерфейс связывается с компонентом с помощью
отношения Interface Rеalization
10

11.

Использование интерфейсов
• Если компонент А использует некоторый интерфейс, который
реализуется другим компонентом В, то такой интерфейс для
компонента А называется импортируемым.
• Связь между компонентом и импортируемым интерфейсом на
диаграмме компонентов изображается с помощью отношения
Usage
• Экспортируемый и импортируемый интерфейсы
изображаются на диаграмме с помощью разных графических
символов, но имеет одно имя. Они связываются между собой
отношением Connector
Экспортируемый интерфейс
Импортируемый интерфейс
11

12.

Выбор предмета
12

13.

Описание системы
• Диаграмма компонентов может быть
использования для разбиения программной
системы на подсистемы.
• Система и подсистемы связываются на
диаграмме с помощью отношения
обобщения
• Для обозначения подсистемы используется
компонент со стереотипом "Subsystem".
• В UML Designer нет отдельного стереотипа
для системы, поэтому можно использовать
стереотип подсистемы.
13

14.

Подсистемы
14

15.

Диаграмма развертывания
• Диаграмма развертывания (deployment diagram)
применяется для представления размещения
артефактов (физических объектов, созданных
человеком) по узлам распределенной
вычислительной системы.
• Диаграмма развертывания содержит графические
изображения физических узлов (процессоров,
устройств, процессов).
• Диаграмма развертывания показывает физические
связи между всеми узлами реализации системы на
этапе исполнения.
• Диаграмма развертывания показывает
распределение артефактов по физическим узлам.
15

16.

Артефакты
• Артефакт - это физическая часть программной системы.
• Обычно артефакт - это некоторый файл, используемый в
системе. Это может быть файл исходного кода, файл
исполняемой программы, документ с описанием
программы и т.д.
• Графическое изображение
• Для показа физической реализации компонента
используется отношение манифестации между
компонентом и артефактом
Это отношение зависимости со стереотипом "manifest".
• В общем случае один компонент может быть связан с
несколькими артефактами.
• Для показа компонента на диаграмме размещения нужно
использовать существующие элементы
16

17.

Примеры артефактов
17

18.

Стереотипы артефактов
• Возможны следующие стереотипы артифактов:
• Document – текстовый документ;
• Executable - исполняемый модуль (например,
файл с расширением ехе);
• Source - файл с исходным текстом программы
или с данными;
• Library - подключаемая библиотека (например,
динамическая библиотека – файл с
расширением dll);
• Script – сценарий, который может быть
выполнен интерпретатором;
• Table - таблица базы данных.
18

19.

Узел
• Узел (node) представляет собой некоторый физический
элемент системы, обладающий некоторым
вычислительным ресурсом.
• Узел - это отдельный компьютер, процессор или
устройство, на котором могут быть развернуты
артефакты.
• Узел - это не обязательно вычислительное устройство.
Им может быть, например, датчик, принтер, сканер,
модем, цифровая камера.
• При описании бизнес-процессов предприятия можно в
качестве узлов системы рассматривать
организационные подразделения, состоящие из
персонала, или отдельных служащих предприятия.
• Для обозначения узла
используется элемент
19

20.

Стереотипы узлов
• Существуют два основных стереотипа узлов:
устройство и среда выполнения.
• Устройство
используется для
обозначения вычислительного узла (локальный
компьютер, сервер) или устройства (монитор,
принтер, датчик).
• Среда выполнения
используется для обозначения некоторой
программной среды. Например, операционная
система Windows, Linux; веб-броузер Google
Chrome, Firefox.
20

21.

Связи и размещение
• Связи между узлами, узлами и артефактами
показываются с помощью отношения
• Узлы среды выполнения могут располагаться
внутри узлов-устройств.
• Артефакты могут располагаться как внутри
устройств, так и внутри сред выполнения.
• Можно также показать расположение артефакта
внутри узла с помощью отношения зависимости со
стереотипом "deploy"
21

22.

Таблицы базы данных
22

23.

Обращение к веб-странице
23

24.

Связи между узлами и артефактами
24

25.

Узлы системы регистрации учебных курсов
25