Проектирование программного обеспечения. Основные диаграммы языка UML Диаграмма компонентов uml требования к функциям

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

С точки зрения реализации проектируемая система состоит из компонентов (представленных на диаграммах компонентов), распределенных по вычислительным узлам (представленным на диаграммах размещения).

В 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 .

Особенности изображения диаграмм языка UML

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

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

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

· Специальные графические символы, изображаемые вблизи от тех или иных визуальных элементов диаграмм и имеющие характер дополнительной спецификации (украшений).

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

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



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

Диаграмма кооперации

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

· показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";

· распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;

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

· изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.

Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм:

· уровень экземпляров (примеров, Instance-Level): отображает взаимодействия между объектами (экземплярами классов); такая диаграмма обычно создается, чтобы исследовать внутреннее устройство объектно-ориентированной системы.

· уровень спецификации (Specification-Level): используется для изучения ролей, исполняемых в системе основными классами.

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



Диаграмма компонентов

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

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

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1, а также интерфейсы 2, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

· реализации между компонентами и интерфейсами (компонент реализует интерфейс);

· зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3.

Диаграмма развертывания

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.

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

При разработке диаграммы развертывания преследуют следующие цели:

· определить распределение компонентов системы по ее физическим узлам;

· показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

· выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

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

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

Диаграмма компонентов разрабатывается для следующих целей:

визуализации общей структуры исходного кода программной системы;

спецификации исполняемого варианта программной системы;

обеспечения многократного использования отдельных фрагментов программного кода;

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

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

Компоненты

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

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

Отдельный компонент может быть представлен на уровне типа или на уровне экземпляра. Графическое изображение в обоих случаях одинаковое, но правила записи имени компонента отличаются. Если компонент представляется на уровне типа, то в качестве его имени записывается только имя типа с заглавной буквы. Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента>":"<имя типаХ>. При этом вся строка имени подчеркивается.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), динамических библиотек (расширение dll), Web-страниц (расширение html), текстовых файлов (расширения txt или doc) или файлов справки (hip), файлов баз данных (DB) или файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение java для языка Java), скрипты (pi, asp) и другие.

Поскольку конкретная реализация логического представления модели системы зависит от используемого программного инструментария, то и имена компонентов определяются особенностями синтаксиса соответствующего языка программирования.

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

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

В языке UML выделяют три вида компонентов:

развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

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

Другим способом спецификации различных видов компонентов является явное указание его стереотипа компонента перед именем. В языке UML для компонентов определены следующие стереотипы:

библиотека (library) - определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки;

таблица (table) - также определяет первую разновидность компонента, который представляется в форме таблицы базы данных;

файл (file) - определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ;

документ (document) - определяет вторую разновидность компонента, . который представляется в форме документа;

исполнимый (executable) - определяет третий вид компонента, который может исполняться в узле.

Интерфейсы

Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.

Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом «интерфейс» и возможными секциями атрибутов и операций. Как правило, этот вариант обозначения используется для представления внутренней структуры интерфейса, которая может быть важна для реализации.

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

Зависимости

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

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

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу. Наличие стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс.

Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов. Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.

На диаграмме компонентов могут быть также представлены отношения зависимости между компонентами и реализованными в них классами. Эта информация имеет значение для обеспечения согласования логического и физического представлений модели системы. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонента используется расширенный символ прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонента, а нижняя секция - для указания дополнительной информации.

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

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

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

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

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

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

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

При разработке диаграммы компонентов следует придерживаться общих принципов создания моделей на языке UML. В частности, необходимо использовать уже имеющиеся в языке UML компоненты и стереотипы. Для большинства типовых проектов этого набора элементов может оказаться достаточно для представления компонентов и зависимостей между ними.

Если проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения и использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.

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

На схеме компонентов показаны части конструкции программной системы. Схема компонентов помогает визуализировать высокоуровневую структуру системы и поведение служб, предоставляемых и потребляемых этими элементами через интерфейсы. Чтобы создать UML-схему компонентов, в меню Архитектура щелкните Создать схему.

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

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

Фигура

Элемент

Описание и основные свойства

Компонент

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

Можно скрывать или отображать внутренние части компонента с помощью элемента управления "развернуть/свернуть" (9).

Компонент - это вид класса.

    Является неявно создаваемым экземпляром. Если значение true (по умолчанию), компонент существует только как артефакт конструкции. Во время выполнения существует только ее часть.

Предоставленный порт интерфейса

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

Требуемый порт интерфейса

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

Зависимость

Может использоваться для указания, что требуемый интерфейс одного компонента может соответствовать предоставленному интерфейсу другого компонента.

Зависимости также можно использовать в более общем случае при работе с элементами модели, чтобы показать, что конструкция одного зависит от конструкции другого.

Атрибут компонента, тип которого, как правило, является другим компонентом. Часть используется при внутреннем проектировании ее родительского компонента. Графически части изображаются вложенными в родительский компонент.

Чтобы создать часть существующего типа компонента, перетащите компонент из Проводника по моделям UML в компонент-владелец.

Чтобы создать часть нового типа, выберите инструмент Компонент и щелкните компонент-владелец.

Например, компонент Car имеет части engine:CarEngine, backLeft:Wheel, frontRight:Wheel и т. д.

Несколько частей могут иметь один и тот же тип, и разные компоненты могут иметь части одного типа.

    Тип. Тип части, определяемый в другом месте модели. Как правило, типом является другой компонент.

    Кратность. По умолчанию используется значение 1. Можно задать значение 0..1, чтобы указать, что часть может иметь значение null, или задать значение *, чтобы указать, что часть является коллекцией экземпляров данного типа. Также в качестве значения можно задать любое выражение, которое можно оценить в числовом диапазоне.

Сборка части

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

Делегирование

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

(не показана)

Обобщение

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

Элемент управления "развернуть/свернуть"

Позволяет скрывать или отображать внутренние части компонента.

(не показана)

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

Существует много хороших книг в которых описано в деталях про UML (местами даже очень подробно), мне хотелось бы собрать в одном месте основные понятия про диаграммы, сущности и связи между ними для быстрого вспоминания, что-то наподобие шпаргалки.

В заметке используется материалы из книжек: Иванов Д. Ю., Новиков Ф. А. Унифицированный язык моделирования UML и Леоненков. Самоучитель по UML .

Для начала определимся с редактором. Под Linux я перепробовал разные UML-редакторы, больше всего мне понравился UMLet , хоть он и написан на Java но шевелится весьма проворно и большинство заготовок сущностей в нем есть. Еще есть ArgoUML кроссплатформенный UML-редактор, написан тоже на Java, функционально-богат но подтормаживает больше.

Я остановился на UMLet , установим его под Arch Linux и Ubuntu :

# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

В UML все сущности можно разбить на такие типы:

  • структурные;
  • поведенческие;
  • группирующие;
  • аннотационные;

В UML используются четыре основных типа отношений:

Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой.

Ассоциация (association) - имеет место, если одна сущность непосредственно связана с другой (или с другими - ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности.

Обобщение (generalization) - это отношение между двумя сущностями, одна из которых является частным (специализированным) случаем другой. Графически обобщение изображается в виде линии с треугольной не закрашенной стрелкой на конце, направленной от частного (подкласса) к общему (суперклассу).

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

В UML 2 определено 13 типов диаграмм. По стандартам каждая диаграмма должна иметь рамку с прямоугольником (правый нижний угол скошенный) в левом верхнем углу, в котором указывается идентификатор диаграммы (тег) и название.

Диаграммы для изображения структуры системы :

  • Диаграмма компонентов (component diagram, тег component );
  • Диаграмма размещения (deployment diagram, тег deployment );
  • Диаграмма классов (class diagram, тег class );
  • Диаграмма объектов (object diagram, тег object );
  • Диаграмма структуры внутренней (composite structure diagram, тег class );

Диаграммы для изображения поведения системы :

  • Диаграмма синхронизации (interaction diagram, тег timing );
  • Диаграмма деятельности (activity diagram, тег activity );
  • Диаграмма последовательности (sequence diagram, тег sd );
  • Диаграмма коммуникации (communication diagram, тег comm );
  • Диаграмма автомата (state machine diagram, тег state machine );
  • Обзорная диаграмма взаимодействия (interaction overview diagram, тег interaction );

Особняком стоят диаграммы:

  • Диаграмма использования(use case diagram, тег use case);
  • Диаграмма пакетов (package diagram, тег package );

Диаграмма использования

Диаграмма использования (use case diagram) - это наиболее общее представление функционального назначения системы.

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

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

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

Отношение расширения - определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.

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

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

Графически данное отношение обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования.

Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми атрибутами и особенностями поведения родительских вариантов.

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

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

Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому.

Диаграмма классов

Диаграмма классов (class diagram) - основной способ описания статической структуры системы.

На диаграмме классов применяется один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и т.д.), между которыми устанавливаются следующие основные типы отношений: зависимости, ассоциации, обобщения, реализации.

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

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику.

Над стрелкой могут находится специальные ключевые слова (стереотипы):

  • "access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
  • "bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
  • "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
  • "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
  • "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения.

Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Применяется для представления системных взаимосвязей типа "часть-целое".

Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части.

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

Диаграмма автомата

Диаграмма автомата (state machine diagram) или диаграмма состояний в UML 1 (state chart diagram) - это один из способов детального описания поведения в UML. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.

Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.

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

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

Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.

Диаграмма деятельности

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

Диаграмма деятельности (activity diagram) - еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Используется для моделирования процесса выполнения операций.

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

На диаграмме деятельности применяют один основной тип сущностей - действие, и один тип отношений - переходы (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.

Диаграмма последовательности

Диаграмма последовательности (sequence diagram) - это способ описания поведения системы "на примерах".

Фактически, диаграмма последовательности - это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей - экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений - связи, по которым происходит обмен сообщениями.

Возможные виды сообщений (изображение взято у larin.in):

Диаграмма коммуникации

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

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

Диаграмма компонентов

Диаграмма компонентов (component diagram) - показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов - это сами компоненты, а также интерфейсы, посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

  • реализации между компонентами и интерфейсами (компонент реализует интерфейс);
  • зависимости между компонентами и интерфейсами (компонент использует интерфейс);

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

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

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

Диаграмма объектов

Диаграмма объектов (object diagram) - является экземпляром диаграммы классов.

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

Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.

Структурный классификатор изображается в виде прямоугольника, в верхней части которого находится имя классификатора. Внутри находятся части (parts). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port). Порты располагаются также на внешней границе структурного классификатора.

Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.

Диаграмма синхронизации

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

Диаграмма пакетов

Диаграмма пакетов (package diagram) - единственное средство, позволяющее управлять сложностью самой модели.

Основные элементы нотации - пакеты и зависимости с различными стереотипами.

Модель сущность-связь (ER-модель)

Аналогом диаграммы классов (UML) может быть ER-модель , которая используется при проектировании баз-данных (реляционной модели).

Модель сущность-связь (ER-модель) - модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. wikipedia

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

Основные понятия:

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов, например, КЛИЕНТ 777 . Сущность фактически представляет из себя множество атрибутов.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Домен (domain) - множество значений (область определения) атрибута.

Существует три типа бинарных связей:

  • один к одному - одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса, напимер, НАЧАЛЬНИК - ОТДЕЛ;
  • 1 к N или один ко многим - одиночный экземпляр сущности одного класса связан со многими экземплярами сущности другого класса, например, ОТДЕЛ - СОТРУДНИК;
  • N к M или многие ко многим - многие экземпляры сущности одного класса связаны со многими экземплярами сущности другого класса, например, СОТРУДНИК - ПРОЕКТ;
  • Словарь основных понятий по UML

    Объект (object) - сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

    Класс (class) - описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

    Интерфейс (interface) - именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.

    Кооперация (collaboration) - совокупность объектов, которые взаимодействуют для достижения некоторой цели.

    Действующее лицо (actor) - сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

    Компонент (component) - модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

    Артефакт (artifact) - элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт - это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).

    Узел (node) - вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

    Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.

    Состояние (state) - период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

    Действие (action) - примитивное атомарное вычисление.

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

    Классификатор (classifier) - это дескриптор множества однотипных объектов.

    Дополнительное чтиво

    • Фаулер М. UML. Основы, 3-е издание
    • Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

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

Для более наглядного изображения компонентов были предложены и стали общепринятыми следующие графические стереотипы:

Во-первых, стереотипы для компонентов развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки (рис. 12, а), Web-страницы на языке разметки гипертекста (рис. 12, б) и файлы справки (рис. 12, в).

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


Рис. 12. Варианты графического изображения компонентов на диаграмме компонентов.

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

Другой способ спецификации различных видов компонентов - указание текстового стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:

<> (файл) – определяет наиболее общую разновидность компонента, который представляется в виде произвольного физического файла.

<> (исполнимый) – определяет разновидность компонента-файла, который является исполнимым файлом и может выполняться на компьютерной платформе.

<> (документ) – определяет разновидность компонента-файла, который представляется в форме документа произвольного содержания, не являющегося исполнимым файлом или файлом с исходным текстом программы.

<> (библиотека) – определяет разновидность компонента-файла, который представляется в форме динамической или статической библиотеки.

<> (источник) – определяет разновидность компонента-файла, представляющего собой файл с исходным текстом программы, который после компиляции может быть преобразован в исполнимый файл.

<

> (таблица) – определяет разновидность компонента, который представляется в форме таблицы базы данных.

Интерфейсы

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

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


Рис. Графическое изображение зависимости между компонентом и классами.

В этом случае из диаграммы компонентов не следует, что классы реализованы данным компонентом. Если требуется подчеркнуть, что некоторый компонент реализует отдельные классы, то для обозначения компонентa используется расширенный символ прямоугольника. При этом прямоугольник компонентa делится на две секции горизонтальной линией. Верхняя секция служит для записи имени компонентa и, возможно, дополнительной информации, а нижняя секция – для указания реализуемых данным компонентом классов

Статьи по теме: