Особенности изображения диаграмм языка UML. Диаграмма Кооперации (Collaboration diagram). Диаграмма Компонентов (component diagram). Диаграмма развертывания (deployment diagram). Элементы графической нотации диаграммы компонентов Описание и основные свой
Цель работы:
- изучение диаграмм пакетов, диаграммы компонентов и диаграммы размещения,
- изучение их применения в процессе проектирования.
Диаграммы пакетов (package diagrams)
Один из важнейших вопросов методологии создания программного обеспечения - как разбить большую систему на небольшие подсистемы? Именно с этой точки зрения изменения, связанные с переходом от структурного подхода к объектно-ориентированному, являются наиболее заметными. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package).
Диаграммой пакетов является диаграмма, содержащая пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов, т. е. диаграмма пакетов - это всего лишь форма диаграммы классов. Однако на практике причины построения таких диаграмм различны.
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменение в другом. Что касается классов, то причины зависимостей могут быть самыми разными: один класс посылает сообщение другому; один класс включает часть данных другого класса; один класс ссылается на другой как на параметр операции. Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может стать неправильным.
В идеальном случае только изменения в интерфейсе класса должны воздействовать на другие классы. Искусство проектирования больших систем включает в себя минимизацию зависимостей, которая снижает воздействие изменений и требует меньше усилий на их внесение.
На рис. 14.1 мы имеем дело с классами предметной области, моделирующими деятельность организации и сгруппированными в два пакета: «Клиенты» и «Заказы».
Рис. 14.1. Классы предметной области, моделирующие деятельность организации
«Приложение сбора заказов» имеет зависимости с обоими пакетами предметной области. «Пользовательский интерфейс сбора заказов» имеет зависимости с «Приложением сбора заказов» и «Библиотекой GUI».
Зависимость между двумя пакетами существует в том случае, если имеется какая-либо зависимость между любыми двумя классами в пакетах. Например, если любой класс в пакете «Список рассылки» зависит от какого-либо класса в пакете «Клиенты», то между соответствующими пакетами существует зависимость.
Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится трудночитаемой.
Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в разрабатываемой системе, однако они помогают выделить эти зависимости. Сведение к минимуму количества зависимостей позволяет снизить связанность компонентов системы. Но эвристический подход к этому процессу далек от идеала.
Пакеты особенно полезны при тестировании. Каждый пакет при тестировании может содержать один или несколько тестовых классов, с помощью которых проверяется поведение пакета.
Диаграммы компонентов (component diagrams)
Компоненты на диаграмме компонентов представляют собой физические модули программного кода (рис. 14.2). Обычно они в точности соответствуют пакетам на диаграмме пакетов (см. рис. 14.1); таким образом, диаграмма компонентов отражает выполнение каждого пакета в системе.
Рис. 14.2.
Зависимости между компонентами должны совпадать с зависимостями между пакетами. Эти зависимости показывают, каким образом одни компоненты взаимодействуют с другими. Направление данной зависимости показывает уровень осведомленности о коммуникации. Если на панелях инструментов диаграмм размещения отсутствуют некоторые значки, то их можно настроить вызвав диалоговое окно View/Toolbar/Configure/Toolbars/Component Diagrams
Таблица 14.1. Описание кнопок панели инструментов диаграмм компонентов Rational Rose
| Кнопка | Описание | Название |
| Выбор элемента модели | Select tool | |
| Ввод текста | Text Box | |
| Комментарий | Note | |
| Связь комментария с элементом | Anchor Note to Item | |
| Компонент | Component | |
| Пакет | Package | |
| Зависимость | Dependency | |
| Тело задания | Task Body | |
| Спецификация задания | Task Specification | |
| Тело пакета | Package Body | |
| Спецификация пакета | Package Specification | |
| Главная программа | Main Program | |
| Спецификация подпрограммы | Subprogram Specification | |
| Тело попдпрограммы | Subprogram Body |
Диаграммы размещения (deployment diagrams)
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером.
На рис. 14.3 изображен персональный компьютер (ПК), связанный с UNIX-сервером посредством протокола TCP/IP. Соединения между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия.
Рис. 14.3.
На практике данные диаграммы применяются не слишком часто. В целом эти диаграммы полезно применять, чтобы выделить особенные физические характеристики данной системы. По мере распространения распределенных систем важность данных диаграмм возрастает.
Таблица 14.2. Описание кнопок панели инструментов диаграмм размещения Rational Rosee
Примеры
Проводить сравнение диаграмм пакетов, компонентов и размещения в общем случае бессмысленно, так как эти диаграммы не существуют сами по себе, а являются интерпретацией некоторой диаграммы классов, для которой и уместно проводить сравнение с другими диаграммами классов.
Диаграммы пакетов содержат один тип элементов - пакет и один тип связей - зависимость, поэтому численная оценка для диаграммы пакетов не столь важна, как для диаграммы классов.
На рис. 14.4 изображена диаграмма пакетов подсистемы «Служба занятости в рамках вуза» системы «Дистанционное обучение». Численная оценка для нее равна:
Рис. 14.4. Диаграмма пакетов
Диаграммы компонентов и размещения строятся и используются на этапе реализации и сопровождения, когда базовая архитектура системы уже обычно определена; поэтому они однозначно получаются из диаграммы классов и для них достаточно привести по одному примеру.
Рис. 14.5 . Диаграмма компонентов
На рис. 14.5 изображена диаграмма компонентов, построенная на основе диаграммы пакетов, изображенной на рис. 14.4. На рис. 14.6 изображена диаграмма размещения подсистемы «Служба занятости в рамках вуза». Оценка для данной диаграммы компонентов равна:
Оценка для диаграммы размещения равна:
Рис. 14.6. Диаграмма размещения
Упражнения
Упражнение 1. Создание диаграммы размещения системы регистрации
Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:
- узел (node) - вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
- соединение (connection) - канал взаимодействия узлов (сеть).
Пример: сетевая конфигурация системы регистрации (без процессов) (рис. 14.7).
Ри с. 14.7. Сетевая конфигурация системы регистрации
Распределение процессов по узлам сети производится с учетом следующих факторов:
- используемые образцы распределения (трехзвенная клиент - серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
- время отклика;
- минимизация сетевого трафика;
- мощность узла;
- надежность оборудования и коммуникаций. Пример: распределение процессов по узлам (рис. 14.8).
Рис.
14.8. Сетевая конфигурация системы регистрации с распределением
Для того чтобы открыть диаграмму размещения, надо дважды щелкнуть мышью по представлению Deployment View (представлению размещения) в браузере.
Для того чтобы поместить на диаграмму процессор:
- На панели инструментов диаграммы нажмите кнопку Processor.
- Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
- Введите имя процессора.
В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК). Характеристики процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.
Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов
- Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
- Non preemptive (без приоритета). У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
- Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
- Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.
- Manual (вручную). Процессы планируются пользователем.
Для того чтобы назначить процессору стереотип.
- Перейдите на вкладку General.
- Введите стереотип в поле Stereotype.
Для введения характеристик и планирования процессора
- Откройте окно спецификации процессора.
- Перейдите на вкладку Detail.
- Введите характеристики в поле характеристик.
- Укажите один из типов планирования.
Для того чтобы показать планирование на диаграмме:
- Выберите пункт Show Scheduling в открывшемся меню.
Для того чтобы добавить связь на диаграмму:
- На панели инструментов нажмите кнопку Connection.
- Щелкните по узлу диаграммы.
- Проведите линию связи к другому узлу.
Для того чтобы назначить связи стереотипа:
- Откройте окно спецификации связи.
- Перейдите на вкладку General.
- Введите стереотип в поле Stereotype (Стереотип).
Для того чтобы добавить процесс:
- Щелкните правой кнопкой мыши по процессору в браузере.
- Выберите пункт New > Process в открывшемся меню.
- Введите имя нового процесса.
Для того чтобы показать процессы на диаграмме:
- Щелкните правой кнопкой мыши по процессору.
- Выберите пункт Show Processes в открывшемся меню.
Контрольные вопросы
- Какую проблему проектирования призваны решить диаграммы пакетов?
- В чем отличие диаграмм пакетов от диаграмм классов?
- В чем смысл зависимости между элементами диаграммы пакетов?
- Что такое интерфейс класса?
- По каким признакам классы группируются в пакеты?
- Какие виды элементов модели представлены на диаграмме компонентов?
- Как связаны между собой диаграммы пакетов и диаграммы компонентов?
- Что показывает диаграмма размещения?
- Какие сущности.отображаются на диаграммах-размещения?
- 10. В каких случаях необходимо применение диаграмм размещения?
Данный раздел посвящен сразу двум диаграммам: компонентов и размещения, для которых можно использовать обобщающее название ‒ диаграммы реализации . Связано это с тем, что данные диаграммы приобретают особую важность на позднейших фазах разработки ‒ на фазах реализации и поставки. В то время как на ранних фазах разработки ‒ анализа и проектирования ‒ эти диаграммы либо вообще не используются, либо имеют самый общий, не детализированный вид.
С точки зрения реализации проектируемая система состоит из компонентов (представленных на диаграммах компонентов), распределенных по вычислительным узлам (представленным на диаграммах размещения).
В UML 2 по сравнению с UML 1 произошло значительное изменение, а именно, понятие "компонент" было разделено на две составляющие: логическую и физическую. Логическая составляющая, продолжающая носить имя компонент (component), является элементом логической модели системы, в то время как физическая составляющая, называемая артефактом (artifact), олицетворяет физический элемент проектируемой системы, размещающийся на вычислительном узле (node).
Диаграммы компонентов и размещения имеют много общего, объединяя воедино следующие, теснейшим образом связанные, вещи:
- структуру логических элементов (компонентов);
- отображения логических элементов (компонентов) на физические элементы (артефакты);
- структуру используемых ресурсов (узлов) с распределенными по ним физическими элементами (артефактами).
В данном разделе мы отступим от правила, принятого нами при описании остальных диаграмм. А именно, мы не будем раздельно для каждой диаграммы рассматривать сущности, применяемые на ней. Более правильным нам кажется совместное рассмотрение всех сущностей и отношений в одном разделе, чем мы и займемся.
3.4.1. Интерфейс
∇ Встречающиеся в литературе варианты перевода: "реализованный", "предоставляемый".
∇∇ Встречающийся в литературе вариант перевода ‒ "запрашиваемый"
Однако, нельзя забывать, что сам по себе интерфейс ‒ это просто описание контракта, а обеспеченным или требуемым он становиться в зависимости от того, как этот интерфейс используется:
- если классификатор реализует интерфейс ‒ то для данного классификатора это обеспеченный интерфейс и данный факт показывается с помощью отношения реализации 3 ;
- если классификатор вызывает операции интерфейса - то для данного классификатора это требуемый интерфейс и данный факт показывается с помощью отношения зависимости 4 .
Разобравшись с интерфейсами, давайте перейдем к компонентам.
3.4.2. Компоненты, артефакты и узлы
Компонент (component) ‒ это модульный фрагмент логического представления системы, взаимодействие с которым описывается набором обеспеченных и требуемых интерфейсов.
С понятием "компонент" часто ассоциируют компонентное или сборочное программирование, однако для UML это соответствие не правомерно. Компонент UML является частью модели, и описывает логическую сущность, которая существует только во время проектирования (design time), хотя в дальнейшем ее можно связать с физической реализацией (артефактом) времени исполнения (run time).
Стандартом UML для компонентов предусмотрены стереотипы, приведенные в следующей таблице.
Табл. Стандартные стереотипы компонентов
Аналогом компонента в смысле сборочного программирования является понятие артефакта в UML. Причем не любого артефакта, а только некоторых из его стереотипов.
Артефакт ‒ это любой созданный искусственно элемент программной системы.
К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты программ, веб-страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическими элементами информации. Другими словами, артефактами являются те информационные элементы, которые тем или иным способом используются при работе программной системы и входят в ее состав.
Для того чтобы как-то отражать такое разнообразие типов артефактов в UML предусмотрены стандартные стереотипы, перечисленные в таблице
Табл. Стандартные стереотипы артефактов
Однако реальные артефакты гораздо разнообразнее по своим типам, чем перечисленные выше. Чтобы как-то учесть это обстоятельство, многие инструменты, помимо стандартных стереотипов, поддерживают дополнительные стереотипы артефактов, часто со специальными значками и фигурами, обеспечивающими высокую наглядность диаграмм.
Самым важным аспектом использования понятия артефакта в UML является то, что артефакт может участвовать в отношении манифестации.
Манифестация ‒ это отношение зависимости со стереотипом «manifest» , связывающее элемент модели (например, класс или компонент) и его физическую реализацию в виде артефакта.
Ниже представлен класс Company , который связан отношением манифестации (зависимость со стереотипом «manifest») с двумя артефактами со стереотипом «source» , которые в свою очередь определяют артефакт времени выполнения динамическую библиотеку (со стереотипом «library») Company .
Вообще говоря, отношение манифестации ‒ это отношение типа "многие ко многим", один элемент модели может быть реализован многими артефактами, и один артефакт может участвовать в реализации многих элементов модели.
Манифестацию графически изображают отношением зависимости со стереотипом «manifest» от артефакта к реализуемой сущности. Поскольку манифестация ‒ это отношение типа "многие ко многим", для полного описания отношения манифестации могут потребоваться несколько отношений зависимости в модели.
Третья сущность, рассматриваемая в этом параграфе ‒ узел.
∇ При использовании UML в других предметных областях, узлом может быть не только компьютер, но и другой объект: человек, механическое устройство и т.д.
В UML предусмотрено два стереотипа для узлов «executionEnvironment» и «device» .
Узел со стереотипом «executionEnvironment» позволяет моделировать аппаратно-программную платформу, на которой происходит выполнение приложения. Примерами среды выполнения являются: операционная система, система управления базами данных и т.д.
Узел со стереотипом «device» также моделирует аппаратно-программную платформу, но допускает возможность вложение одного узла в другой, как это показано на следующем рисунке.
Артефакты системы во время ее работы размещаются на узлах, что графически выражается либо их перечислением внутри узла 1 (см. рисунок выше), либо отношением зависимости со стереотипом «deploy» между артефактом и узлом 1 (см. рисунок ниже), либо изображением артефакта внутри изображения узла 2 (см. рисунок ниже). Все варианты нотации равноправны.
Если при размещении артефакта на узле важную роль играют специфичные для программной среды параметры, то они могут быть заданы посредством спецификации развертывания (deployment specification).
Спецификация развертывания изображается, как и классификатор (в виде прямоугольника), но со стереотипом «deploymentSpec» и связывается отношением зависимости с артефактом.
Последнее, что нам осталось рассмотреть в рамках данного параграфа ‒ это отношение ассоциации между узлами.
Если узлы связаны между собой отношением ассоциации, то это означает то же, что и в других контекстах: возможность обмена сообщениями. Применительно к вычислительным сетям, состоящим из узлов, ассоциация означает наличие канала связи. Если нужно указать дополнительную информацию о свойствах канала, то это можно сделать, используя общие механизмы: стереотипы (например, «tcp/ip» см. на рисунке ниже), ограничения и именованные значения.
На этом мы закончим данный обзорный параграф, чтобы в следующем подробнее познакомится с диаграммами компонентов и размещения на примере информационной системы отдела кадров.
3.4.3. Применение диаграмм компонентов и размещения
Давайте попытаемся ответить на вопрос, какие интерфейсы, компоненты и артефакты можно выделить в информационной системе отдела кадров, а также как целесообразно разместить разработанное программное обеспечение на вычислительных узлах.
Основное назначение проектируемой информационной системы ‒ хранить данные о кадрах и выполнять по указанию пользователя некоторые операции с этими данными. Анализируя состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД (DBMS ‒ Data Base Management System). С точки зрения проектирования информационной системы отдела кадров целесообразно считать используемую СУБД готовым компонентом с заранее определенными интерфейсами и протоколом взаимодействия. Мы можем не заострять внимания на структуре этого компонента ‒ она стандартна и, наверное, достаточно хорошо описана вне нашей модели.
СУБД возьмет на себя все функции по непосредственному манипулированию данными: создание, удаление и поиск записей в таблицах и т.д. Реализация операций нашей информационной системы отдела кадров сводится к некоторой последовательности элементарных операций с данными. Например, операция перевода сотрудника с одной должности на другую, видимо, потребует изменения в трех элементах данных: в данных о сотруднике и в данных о старой и новой должностях. Однако целесообразно ли считать, что определение и выполнение самой последовательности элементарных операций с данными также является прерогативой выделенного нами компонента ‒ СУБД? Общепринятая практика отвечает на этот вопрос отрицательно. По многим причинам лучше выделить это в отдельный компонент, обычно называемый бизнес-логикой ∇ . Кроме этого, мы должны предположить, что в нашей системе должен быть компонент, ответственный за пользовательский интерфейс. В первом приближении мы приходим к структуре компонентов, приведенной ниже, которая называется «трехуровневая архитектура».
∇ Крайне неудачный, но часто используемый термин, являющийся калькой английского business logic. Бизнес-логика не имеет никакого отношения ни к бизнесу (в российском понимании этого слова), ни к логике. Правильнее было бы использовать сложное словосочетание "правила обработки данных", но мы боимся оказаться непонятыми.
В версии UML 2 произошли следующие изменения в нотации диаграмм компонентов.
Во-первых, компоненты, как и любой классификатор, можно изображать единообразно, в виде прямоугольников, в которых, указывается либо стереотип «component» 1 , либо один из уточняющих стереотипов, приведенных в табл. Стандартные стереотипы компонент в параграфе 3.4.2 2 , либо соответствующий значок в правом верхнем углу прямоугольника 3 .
Во-вторых, требуемые и обеспеченные интерфейсы можно изображать с помощью нотации "чупа-чупс" 4 (см. параграф 3.3.1), так что отношение взаимодействия компонентов через некоторый интерфейс выглядит естественным и симметричным.
Сказанное иллюстрирует рисунок ниже на котором указаны те же сущности и отношения, что и на рисунке выше.
Приведенный пример диаграммы компонентов достаточно тривиален и выглядят не слишком убедительно с точки зрения полезности при архитектурном проектировании. Осознавая этот недостаток, мы приведем еще один пример, связанный с информационной системой отдела кадров, в котором постараемся показать, что диаграммы компонентов являются достаточно выразительным средством проектирования архитектуры.
Допустим, что в проектируемой информационной системе отдела кадров требуется разграничить права на выполнение операций и доступ к данным для различных категорий пользователей. Хотя в нашем техническом задании про это не сказано ни слова, но для современных систем данное требование стало общим местом (иногда явно лишним), так что пример не является надуманным. Нам известно множество способов реализации разграничения прав доступа к данным, а неизвестных нам способов, наверное, существует еще больше. Мы не будем вдаваться в их описание и обсуждение, а ограничимся одним - очень простым, но действенным. У нашего приложения два действующих лица (см. параграф 2.2.1), т.е. две категории пользователей. Допустим, что достаточно разграничить права на уровне категорий пользователей. Тогда можно поступить следующим образом: сделать просто два различных приложения (или, как обычно говорят в таких случаях, два автоматизированных рабочих места ‒ АРМа). Пользователи, имеющие доступ к АРМу в целом, могут выполнять все операции АРМа и, таким образом, имеют те и только те права на доступ к данным, которые обеспечиваются операциями, реализованными в АРМе.
Для приложения типа информационной системы отдела кадров такого решения практически достаточно. Таким образом, разграничение прав доступа к данным переносится на уровень доступа к компьютерам и установленным на них приложениям, а это уже проблемы операционных систем и служб безопасности предприятия, о которых в информационной системе отдела кадров можно не заботиться.
Принятое решение легко выражается на диаграмме компонентов.
Все что осталось сделать ‒ это определить состав компонентов, т.е. показать какие классы в какие компоненты входят.
Самый простой способ показать связь между компонентом и входящими в него классами ‒ использовать отношение реализации 1 , как это представлено ниже.
Другой способ определения состава компонента ‒ рассматривать его как структурированный классификатор и использовать диаграмму внутренней структуры (см. параграф 1.6.2 и параграф 3.5.1).
Следующим структурным аспектом, который необходимо обсудить, является описание размещения артефактов относительно участвующих в работе вычислительных ресурсов.
Если речь идет о настольном приложении, которое целиком хранится и выполняется на одном компьютере, то отдельная диаграмма размещения не нужна ‒ достаточно диаграммы компонентов (а может быть, и без нее можно обойтись). При моделировании распределенных приложений значение диаграмм размещения резко возрастает: они являются описанием топологии ∇ развернутой системы.
∇ Программисты заимствовали название раздела математики (топология) как термин. Например, часто можно встретить выражение "топология локальной сети". Нельзя сказать, что такое заимствование совершенно неверно, но в то же время оно и не совсем по существу. Речь идет просто об описании структуры связей конечного множества узлов, т.е. о графе.
Продолжим рассмотрение информационной системы отдела кадров в этом аспекте. Допустим, что мы приняли архитектуру, приведенную выше на рисунке "Диаграмма компонентов ИС OK". Сколько компьютеров будет использоваться при работе данного приложения? На этот вопрос нужно отвечать также вопросом: а сколько пользователей будет у системы и сколько из них будут работать с приложением одновременно? Если имеется только один пользователь (или, хуже того, нашу систему установят "для галочки", а использовать не будут), то проблем нет ‒ настольное приложение ‒ один компьютер и диаграмма размещения не нужна. Допустим, что у нашей системы должно быть много пользователей, и они могут работать одновременно. Тогда ответ очевиден: узлов должно быть не меньше, чем число одновременно работающих пользователей, потому что вдвоем за одним персональным компьютером обычным пользователям работать неудобно. Скорее всего, узлов должно быть на единицу больше чем пользователей, т.к. в большинстве организаций есть специально выделенный компьютер (сервер) для хранения корпоративных данных. Там мы и поместим нашу базу данных, в расчете на то, что нужная СУБД, скорее всего, на сервере уже установлена. Остается вопрос о размещении артефактов, реализующих бизнес-логику. Здесь возможны разные варианты: на компьютере пользователя, на промежуточной машине (сервере приложений), на корпоративном сервере баз данных. Если мы остановимся на последнем варианте (который на жаргоне называется "архитектура клиент/сервер с тонким клиентом"), то получим диаграммы, приведенные на следующих двух рисунках.
Обе эти диаграммы являются диаграммами размещения, но каждая из них имеет свои особенности. На первой диаграмме упор сделан на указание соответствия между компонентами и артефактами, выражающийся в наличии большого количества отношений зависимости со стереотипом «manifest» (см., например, 1 на первой диаграмме). Вторая диаграмма показывает отношения между артефактами, или, другими словами, определяет, какой артефакт от какого зависит, например, запрашивает данные (в качестве примера см. 1 на второй диаграмме). На обеих диаграммах показаны вычислительные узлы и отношения между ними (2 на обоих диаграммах). Заметим, что на диаграмме появился дополнительный артефакт ‒ Help (например, 3 на второй диаграмме). Это документ, содержащий справочную информацию.
В завершении параграфа дадим несколько советов по поводу того, в каких случаях следует применять диаграммы компонентов и размещения.
Начнем с уже высказанного элементарного соображения: в случае разработки "монолитного" настольного приложения диаграммы размещения не нужны ‒ они оказываются тривиальными и никакой полезной информации не содержат. Таким образом, диаграммы размещения применяются только при моделировании многокомпонентных приложений.
Если приложение поставляется в виде "конструктора" (набора "кубиков") из которого при установке собирается конкретный уникальный экземпляр приложения, то диаграммы размещения оказываются просто незаменимым средством. Действительно, многие современные приложения, особенно развитые системы автоматизации управления делопроизводством предприятия, поставляются в виде большого (десятки и сотни) набора артефактов, из которых "на месте" собирается нужная пользователю, часто уникальная, конфигурация. Некоторые авторитетные источники рекомендуют использовать диаграммы размещения для управления конфигурацией не только на фазе поставки и установки программного обеспечения, но и в процессе разработки: для отслеживания версий компонентов, вариантов сборки и т.п.
При разработке приложений, которые должны взаимодействовать с так называемыми унаследованными (legacy) приложениями и данными, без диаграмм компонентов трудно обойтись. Дело в том, что фактически единственным средством UML, позволяющим как-то описать и включить в модель унаследованные приложения и данные являются компоненты (и их интерфейсы). Сюда же относится случай моделирования доступа к данным из "неродной" СУБД.
Последним (в нашем списке) примером применения диаграмм размещения является моделирование систем динамической архитектуры, то есть таких систем, которые меняют состав и количество экземпляров своих артефактов во время выполнения ∇ . Например, многие web-приложения меняют свою конфигурацию во время выполнения в зависимости от текущей нагрузки. Информационная система отдела кадров не является системой динамической архитектуры, поэтому мы не приводим примера.
∇ Отметим еще раз, что во время выполнения мы имеем дело не с самими классификаторами, а с их экземплярами. Представлению экземпляров классификаторов посвящен параграф 3.5.4 .
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Компонент (component) - физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
Для более наглядного изображения компонентов были предложены и стали общепринятыми следующие графические стереотипы:
Во-первых, стереотипы для компонентов развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки (рис. 12, а), Web-страницы на языке разметки гипертекста (рис. 12, б) и файлы справки (рис. 12, в).
Во-вторых, стереотипы для компонентов в форме рабочих продуктов. Как правило – это файлы с исходными текстами программ (рис. 12, г).
Рис. 12.
Варианты графического изображения компонентов на диаграмме компонентов.
Эти элементы иногда называют артефактами , подчеркивая при этом их законченное информационное содержание, зависящее от конкретной технологии реализации соответствующих компонентов. Более того, разработчики могут для этой цели использовать самостоятельные обозначения, поскольку в языке UML нет строгой нотации для графического представления артефактов.
Другой способ спецификации различных видов компонентов - указание текстового стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:
<
<
<
<
<
<
