Типы отношений языка uml
UML-диаграммы классов
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:
Сущности – это абстракции, которые являются основными элементами модели, связи соединяют их между собой, а диаграммы группируют представляющие интерес наборы сущностей.
Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.
Сущности
Диаграммы классов оперируют тремя видами сущностей UML:
Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.
Структурные сущности — классы
Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:
Для атрибутов и операций может быть указан один из трех типов видимости:
Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы). 
Для абстрактного класса имя класса записывается курсивом.
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует. 
Отношения между классами
Существует четыре типа связей в UML:
Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации. 
Двойные ассоциации представляются линией без стрелок на концах, соединяющей два классовых блока.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Пример кода и диаграммы классов для него
Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.
Введение в UML
Принципы моделирования
Использование языка UML основывается на следующих общих принципах моделирования:
Сущности в UML
Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:
Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и другие группирующие сущности. В отличие от компонентов, которые реально существуют во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только в процессе разработки.
Отношения в UML
Реализация (realization) является семантическим отношением между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях:
Общие механизмы UML
Для точного описания системы в UML используются, так называемые, общие механизмы :
Практически каждый элемент UML имеет уникальное графическое изображение, которое дает визуальное представление самых важных его характеристик. Нотация сущности «класс» содержит его имя, атрибуты и операции. Спецификация класса может содержать и другие детали, например, видимость атрибутов и операций, комментарии или указание на то, что класс является абстрактным. Многие из этих деталей можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, который изображает класс.
При моделировании объектно-ориентированных систем существует определенное деление представляемых сущностей.
Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.
Виды диаграмм UML
Каждая из этих диаграмм конкретизирует различные представления о модели системы. При этом, диаграмма вариантов использования представляет концептуальную модель системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является логической моделью, отражающей статические аспекты структурного построения системы, а диаграммы поведения, также являющиеся разновидностями логической модели, отражают динамические аспекты её функционирования. Диаграммы реализации служат для представления компонентов системы и относятся к ее физической модели.
Для диаграмм языка UML существуют три типа визуальных обозначений, которые важны с точки зрения заключенной в них информации:
При графическом изображении диаграмм рекомендуется придерживаться следующих правил:
3) Отношения UML
Что такое UML Relationship?
Отношения в UML используются для представления связи между структурными, поведенческими или группирующими вещами. Это также называется ссылкой, которая описывает, как две или более вещи могут относиться друг к другу во время выполнения системы. Тип отношений UML: Ассоциация, Зависимость, Обобщение и Реализация.
Давайте изучим их подробно
Это набор ссылок, которые связывают элементы модели UML. Он также определяет, сколько объектов принимают участие в этом отношении.
В зависимости зависимости, как следует из названия, два или более элементов зависят друг от друга. При таком типе отношений, если мы вносим изменения в конкретный элемент, вероятно, что все остальные элементы также будут затронуты этим изменением.
Это также называется отношениями родитель-ребенок. В общем, один элемент является специализацией другого общего компонента. Это может заменить его. Это в основном используется для представления наследства.
В отношениях реализации UML одна сущность обозначает некоторую ответственность, которая не реализована сама собой, а другая сущность реализует их. Эта связь чаще всего встречается в случае интерфейсов.
В этом уроке по UML вы узнаете:
ассоциация
Это структурные отношения, которые представляют объекты, которые могут быть связаны или связаны с другим объектом внутри системы. Следующие ограничения могут быть применены к отношениям ассоциации.
Мы также можем создать класс, который имеет свойства ассоциации; это называется как ассоциативный класс.
Рефлексивная ассоциация
Рефлексивная ассоциация является подтипом ассоциативных отношений в UML. В рефлексивной ассоциации экземпляры одного и того же класса могут быть связаны друг с другом. Экземпляр класса также называется объектом.
Рефлексивная ассоциация утверждает, что в объектах одного и того же класса может присутствовать ссылка или соединение.
Давайте рассмотрим пример сорта фруктов. У класса фруктов есть два экземпляра, например, манго и яблоко. Рефлексивная ассоциация утверждает, что может присутствовать связь между манго и яблоком, поскольку они являются экземплярами одного и того же класса, например фруктами.
Направленная ассоциация
Как следует из названия, направленная ассоциация связана с направлением потока внутри классов ассоциации.
В направленной ассоциации поток направлен. Ассоциация от одного класса к другому течет только в одном направлении.
Обозначается сплошной линией со стрелкой.
Вы можете сказать, что между сервером и клиентом существует целенаправленная связь. Сервер может обрабатывать запросы клиента. Этот поток является однонаправленным, который передается только от сервера к клиенту. Следовательно, в серверах и клиентах системы могут присутствовать отношения направленной ассоциации.
зависимость
Используя отношение зависимости в UML, можно объяснить, как различные вещи в конкретной системе зависят друг от друга. Зависимость используется для описания отношений между различными элементами в UML, которые зависят друг от друга.
Стереотипы
Стереотипы среди государственной машины
Обобщение
Это отношения между общей сущностью и уникальной сущностью, которая присутствует внутри системы.
При наследовании дочерний элемент любого родителя может получать доступ, обновлять или наследовать функциональность, указанную внутри родительского объекта. Дочерний объект может добавлять свои функциональные возможности самому себе, а также наследовать структуру и поведение родительского объекта.
Этот тип отношений все вместе известен как обобщающие отношения.
Стереотипы и их ограничения
Отношение обобщения содержит такие ограничения, как полное, неполное, чтобы проверить, включены ли все дочерние объекты в отношение или нет.
реализация
В отношениях реализации UML одна сущность обозначает некоторую ответственность, которая не реализована сама собой, а другая сущность реализует их. Эта связь чаще всего встречается в случае интерфейсов.
Реализация может быть представлена двумя способами:
На приведенной выше схеме бизнес-правила учетной записи реализуют интерфейс IRuleAgent.
Типы реализации:
В отношениях реализации UML каноническая форма используется для реализации интерфейсов в системе. Он использует стереотип интерфейса для создания интерфейса, а отношения реализации используются для реализации конкретного интерфейса.
В канонической форме отношение реализации обозначается с помощью пунктирной направленной линии с большой открытой стрелкой.
На приведенной выше схеме интерфейс Iruleagent реализован с использованием объекта, называемого бизнес-правилами учетной записи.
Реализация на диаграмме классов UML также может быть показана с использованием формы elided. В форме исключения интерфейс обозначается с помощью круга, который также называется обозначением леденца на палочке.
Этот интерфейс, когда реализован с использованием чего-либо, присутствующего внутри системы, создает элитную структуру.
На приведенной выше схеме интерфейс Iruleagent обозначен с использованием элидируемой формы, которую реализует acctrule.dll.
Сочинение
Это не стандартное отношение UML, но оно все еще используется в различных приложениях.
Составная агрегация является подтипом агрегационной связи с характеристиками как:
Композитная агрегация описывается как бинарная ассоциация, украшенная черным ромбом с заполнением на агрегированном (целом) конце.
Папка — это структура, в которой содержится n файлов. Папка используется для хранения файлов внутри нее. Каждая папка может быть связана с любым количеством файлов. В компьютерной системе каждый отдельный файл является частью как минимум одной папки внутри системы организации файлов. Этот же файл также может быть частью другой папки, но это не обязательно. Всякий раз, когда файл удаляется из папки, папка остается неизменной, тогда как данные, относящиеся к этому конкретному файлу, уничтожаются. Если операция удаления выполняется для папки, то она также влияет на все файлы, которые находятся внутри папки. Все файлы, связанные с папкой, автоматически удаляются после удаления папки из системы.
Этот тип отношений в UML известен по сложным отношениям агрегации.
агрегирование
Агрегация является подтипом отношения ассоциации в UML. Агрегация и состав являются типами ассоциативных отношений в UML. Отношения агрегации можно описать простыми словами как «объект одного класса может владеть или получать доступ к объектам другого класса».
В отношении агрегации зависимый объект остается в области отношения, даже если исходный объект уничтожен.
Давайте рассмотрим пример автомобиля и колеса. Автомобиль нуждается в колесе, чтобы функционировать правильно, но колесо не всегда нуждается в автомобиле. Его также можно использовать с велосипедом, велосипедом или любым другим транспортным средством, но не с конкретным автомобилем. Здесь объект колеса имеет смысл даже без объекта автомобиля. Такой тип отношений называется отношением агрегации.
UML для самых маленьких: диаграмма классов
Аве, Кодер! Диаграмма классов UML иллюстрирует структуру системы, описывая классы, их атрибуты, методы и отношения между объектами.
Даже самые малые детки знают, что UML происходит от Unified Modeling Language, если по- русски, то — унифицированный язык моделирования, который, как гласит легенда, разработали, когда серьезные дяди и тети в конец задолбались плавать в разнообразии кружочков, черточек и облачков.
Для тех, кому лень читать:
Главное действующее лицо
Для начала напомним себе что такое класс? Если в двух словах, то класс представляет собой шаблон для создания объектов, обеспечивающий начальные значения состояний: инициализацию полей-переменных и реализацию поведения полей и методов.
По сути, класс описывает то, каким объект может быть.
Класс представляет концепт, который описывает состояние (атрибуты) и поведение (методы). Каждый атрибут имеет свой тип, каждый метод — свою сигнатуру, но в диаграмме классов только имя класса является обязательной информацией к заполнению, что и логично — даже лучшие экстрасенсы мира не смогут понять, что это за безымянный квадрат и к чему он вообще относится.
Имя класса пишется в самом верхнем делении, затем идут атрибуты класса, типы которых записываются после двоеточия и, наконец, в нижнем делении идут методы.
Тип, который может возвращать метод, записывается после двоеточия в самом конце сигнатуры метода. Модификаторы области видимости изображены перед атрибутами класса и методами.
Каждый параметр в методе может также иметь описание направленности метода: in, out, inout.
На этой иллюстрации, method1 использует p1, как входной параметр и значение p1, каким-то образом, используется методом, а метод не изменяет p1.
Method2 принимает p2, как параметр ввода/вывода, значение p2, каким-то образом, используется методом и принимает выходное значение метода, но сам метод также может изменять p2.
Method3 использует p3, как выходной параметр, иными словами, параметр служит хранилищем для выходного значение метода.
Перспективы диаграммы классов в жизненном цикле разработки программного обеспечения
Мы можем использовать диаграммы классов на разных этапах жизненного цикла разработки программного обеспечения и, как правило, постепенно моделируя диаграммы классов с трех разных точек зрения по мере нашего продвижения по уровням детализации.
Концептуальная перспектива — это когда диаграммы интерпретируются как описание вещей в реальном мире. Таким образом, если мы берем концептуальную перспективу, мы рисуем диаграмму, которая представляет концепции в изучаемой области. Эти концепции относятся к классам, которые их реализуют. Концептуальная перспектива считается независимой от языка.
Спецификационная перспектива — это когда диаграммы интерпретируются, как описание абстракций программного обеспечения или компонентов со спецификациями и интерфейсами, но без привязки к конкретной реализации.
Имплементационная перспектива — это когда диаграммы интерпретируются, как описание реализаций программного обеспечения на определенной технологии и языке.
Таким образом, если ты берешь имплементационную перспективу, ты смотришь на реализацию программного обеспечения.
Типы отношений
Далее, я приведу шесть основных типов обозначений отношений между классами, которые встречаются в UML схемах чаще всего.
Ассоциация. 
Аналогично связям, соединяющим объекты, ассоциации соединяют классы. Для того, чтобы между объектами была связь, между ними должна быть ассоциация.
Если предположить, что у нас есть два класса, которые взаимодействуют друг с другом, между ними должна быть проведена непрерывная соединительная линия, обозначающая на схеме ассоциацию. Часто мы также можем увидеть глагол, передающий ее смысл.
Помимо этого, мы также можем указать кратность, то есть число объектов, которые могут принимать участие в отношениях. Кратность задается в виде разделенного запятыми списка интервалов, в котором каждый интервал представлен в виде минимум-максимум.
Например, один студент может учиться у множества преподавателей.
Но и преподаватель может учить множество студентов.
Или иногда его еще называют — генерализация.
Как следует из названия, это схематическое изображение отношения между родительским классом и его наследниками. Полая стрелка всегда направлена к классу «родитель».
Классический пример наследования: классы квадрат, прямоугольник и круг, которые являются наследниками родительского класса «фигура».
Мы вправе изображать наследование как отдельно для каждого класса, так и объединять их.
Если наследование происходит от абстрактного класса, то имя такого родительского класса записывается курсивом.
Обычно, под этим подразумевается отношение интерфейса и объектов, реализующих этот интерфейс.
Например, интерфейс Owner имеет методы для покупки и продажи частной собственности, а отношения классов Person и Corporation, реализующих этот интерфейс, на диаграмме будут обозначаться в виде пунктирной линии со стрелкой по направлению к интерфейсу.
Объект одного класса может использовать объект другого класса в своем методе.
Если объект не хранится в поле класса, то такой вид межклассовых отношений моделируется как зависимость.
Зависимость, по сути, является специальным случаем ассоциации двух классов, в этом случае, изменения в одном классе неумолимо повлекут за собой изменения в другом.
Например, у класса Person есть метод hasRead с входным параметром book, который возвращает true, если, к примеру, человек прочитал книгу.
Зависимость обозначается пунктирной линией со стрелкой, обращенной к классу, от которого зависят, например, методы другого класса.
Особый тип отношений между классами, когда один класс является частью другого.
Например, рабочее место программиста состоит из стула, стола, компьютера и вентилятора, но при удалении класса «рабочее место», у нас просто останутся все эти классы, только по отдельности.
Агрегация показана в виде непрерывной линии с полым ромбом направленным от классов, являющимися частью какого-либо класса к классу-агрегатору.
По сути, разновидность агрегации, только в этом случае, классы, являющиеся частью другого класса, уничтожают, когда уничтожается класс-агрегатор.
Например наше тело состоит из органов, но сами по себе они не жизнеспособны.
Композиция обозначается схожим с агрегацией способом, но ромб на этот раз полностью закрашен.
Финалочка
UML бывает очень полезен для новичков, находящихся на этапе понимания «что к чему долждно идти и от чего наследоваться». Как говорят наши англоязычные коллеги: «он помогает увидеть как выглядит весь лес за стволами деревьев».
Поэтому, перед началом твоего, пусть и небольшого, но сногсшибательного проекта, не хватайся сразу за код. Создай сперва архитектуру своего приложения в UML.