uml что это такое простыми словами
«UML. Взгляд со стороны» или «Как UML удерживает аналитиков в прошлом»
Изображение с www.uml.org
И как следствие: Аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад. Сама концепция хорошая, но нужно соотносить ее с местом и контекстом применения.
Если дальше продолжить этот анализ применения UML, а также соотнести его с требованиями текущего времени, то выводы такие:
Аспекты представления
Что делает аналитик, когда пытается увязать все диаграммы в одну модель? Он начинает строить гибридные диаграммы и таблицы связей. В результате получается не единая модель, а множество диаграмм, к которому добавились еще диаграммы и таблицы.
Уровни представления
Допустим бизнес-аналитик описал предметную область с помощью диаграмм UML. И теперь системному аналитику или тому же самому аналитику требуется сформировать модель программной системы. Если аналитик ориентирован на UML, то начнет создавать представления соответствующие сделанным ранее, но уже в рамках системы. Это будет выглядеть опять в виде аналогичных диаграмм.
А что будет делать аналитик, когда захочет сопоставить описание предметной области и модели системы?
Он опять начинает строить гибридные диаграммы, таблицы связей и трассировки.
В результате опять получается множество диаграмм и таблиц.
Тут еще нужно заметить, UML старый язык и для него имеется огромное количество книг и старых примеров. В которых в основном описываются случаи перехода от неавтоматизированного бизнеса к автоматизированному. И аналитики учатся на этих примерах. Но ведь на сегодняшний день информационные технологии проникли повсюду. Подход «Бизнес отдельно, ИТ отдельно» неприемлем.
Сервис-ориентированный подход
UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции. Например, сервис-ориентированную. В стандартном профиле UML нет понятия «Сервис», но есть профиль SoaML, который преподносится как язык моделирования сервис-ориентированной архитектуры.
Коротко расскажу про сервис-ориентированный подход, чтобы далее было понятно почему SoaML не подходит для его моделирования. За основу возьмем интерпретацию определений из TOGAF.
Человек и Магазин
Задача: Описать модель покупки товара в магазине.
Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.
Человек выступает не как пользователь, а как одна из сторон взаимодействия.
Теперь решим данную задачу с помощью SoaML, строго в соответствии со спецификацией.
На этой диаграмме определяем сообщество взаимодействующих, это Магазин и Человек.
Определяем действующий между ними бизнес-процесс «Продажа товара», в котором Магазин выступает как «продавец», а Человек как «покупатель».
На основе бизнес-процесса мы теперь можем идентифицировать следующий бизнес-сервис, в SoaML для этого используется классификатор ServiceContract.
В рамках данного сервиса: Продавец выступает как provider, а Покупатель как consumer.
Продавец как поставщик предоставляет одну операцию «продать». Бизнес-анализ закончен, переходим на уровень системы.
Нам нужно смоделировать на уровне системы обновленную версию нашего бизнес-процесса по продаже товара. Для этого я выбрал диаграмму последовательности, можно использовать любую другую поведенческую диаграмму.
Из обновленного бизнес-процесса можно выделить одну операцию «продать», оформим ее в базовый интерфейс «Умеющий продавать».
Далее нам нужно описать сервисные интерфейсы, которые будут использованы для реализации сервиса.
Теперь можно представить модель целевого сервиса в виде диаграммы композитной структуры.
Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.
Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?
Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.
А сейчас закончим рассмотрение SoaML на более сложном случае, тогда получаться у нас будут примерно следующие схемы.
Что же не так, по моему мнению, с SoaML.
Во-первых: Опять проблемы с целостностью языка и связью между уровнем бизнеса и уровнем приложений, вы сами видели как сложно всё соотносится друг с другом.
Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза «Поставщик представляет сервис», вот это компонент-ориентированный подход, который реализован в SoaML. Но в случае с сервис-ориентированной парадигмой правильнее говорить «Поставщик оказывает сервис». А если по другому перевести «Сервис» на русский язык, то всё сразу встает на свои места: «Поставщик оказывает услугу». С этой точки зрения «Сервис» это не «Объект», это «Поведение».
В-третьих: На слайде о сервис-ориентированной архитектуре я рассказал о двух абстракциях: Процесс и Сервис. Рассматривать и описывать их через призму объектно-ориентированного подхода является, мягко говоря, напряженной задачей.
Парадигмы
Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.
И если с компонент-ориентированной парадигмой всё получается, она может быть представлена как логическое продолжение объектно-ориентированной. То с сервис-ориентированной получилось нехорошо.
В данном случае выражать одну парадигму через другую неудачная идея.
Использование такой концепции я продемонстрировал с SoaML на примере задачи «Человек и Магазин».
Относится к парадигмам лучше как обозначено ниже.
Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.
Человек и Собака
Задача: Описать модель взаимодействия – Человек гуляет с Собакой.
Данную задачу не задумываясь, наверное, решит любой студент технического факультета. В школах и универах на соответствующих специальностях объектно-ориентированное программирование является обязательным. Объектно-ориентированный подход представлен ниже.
А как будет выглядеть модель с сервис-ориентированным подходом? Не знаю, ответит ли такой вопрос студент.
Нужно понимать, что это простая задача и это простая модель. Но она отражает суть сервис-ориентированного подхода. Человек предоставляет (оказывает) для Собаки сервис (услугу) «Гулять».
Можно вспомнить историю объектно-ориентированного программирования. Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт. И до сих пор некоторые люди считают ООП недостойным внимания.
Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования. Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.
Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу «Гулять». Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод «гулять», на вход которому подается Собака. Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.
Нужно заметить, что эти парадигмы вполне совместимы. Человек по-прежнему может выполнять свойственные ему действия: спать и танцевать, а Собака лаять.
Еще один момент: В этом примере я ввел новое понятие «Сервис». При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.
UML, Классы и Отношения
Существует много разработанных теорий, задокументированных технологий и парадигм программирования. Перед тем как углубиться с головой в их изучение было бы мудро изучить сам принцип взаимодействия программ и их структур. UML предлагаем вам разработанный стандарт что бы сделать это.
Эту статью я бы хотел посвятить одному из небольших разделов UML — диаграмме классов (class diagrams)
Перед изучением автор советует иметь под рукой UML редактор или «поиметь» сейчас один из след UML редакторов:
думаю они уже были разобраны вот в этой статье habrahabr.ru/blogs/webdev/42812
Эта статья не вдается во все тонкости UML, она посвящена базовым навыкам, таким как понимание связей и отношений классов или других структур данных
Что такое диаграммы классов?
Понятие класса диаграммы представляет собой описание сущности и его отношений. Сущность в большинстве случает представляет класс или интерфейс который содержится в вашем коде, но иногда сущность может ссылаться на более абстрактные объекты или даже на типы данных
Представление Классов
все очень просто:
Вверху пишется имя класса
Средняя часть компонента представлена в виде свойств, ссылок и атрибутов
Нижняя часть компоненты представлена в виде операций которые в большинстве случаев соответствуют методам в коде, подчёркнутые операции означают статическую операцию
Названия абстрактных классов будет выделено курсивом
Интерфейсы представлены идентично по отношению к классам за исключением того что в название будет добавлено ключевое слово
Пакеты
Пакет это сущность которая представляет собой группу классов и интерфейсов. В основах UML пакет представлен в след виде:
Типы данных
Типы данных — это тоже сущности, но за исключением классов они не могут быть представлены отдельно в диаграмме классов — они всегда связанны с атрибутом, принадлежат входным аргументам или возвращающим значением.
Представление различных типов видимости данных в UML
+ public
# protected
— private
UML не ограничена только виденьем членов класса — сам класс может иметь своё виденье тоже. Если вы хотите посмотреть «на всю картину» вам нужно использовать пакетную диаграмму.
Отношения
Последовательное представление отношений сущностей очень полезно. Самая главная часть диаграммы классов — это отношение.
Ниже представлены всех отношения которые мы будем рассматривать:
Associations
Bi-directional asociation (standart association)
Uni-directional association
Associationo class (drop class)
Aggregation
Regular aggregation
Composition (composite aggregation)
Generalizations
Dependencies
Assocations
Assocations — это отношение между двумя классификаторами, описывающее связь между их экземплярами. Ассоциации имеют навигацию, показывая отношение одного класса к другому. Каждая сущность вовлечённая в эту связь выполняет определённую роль, роли могут быть назначены.
Так же здесь могут быть разные отношения между сущностями:
0..1 ноль или один
1 только один
0..* ноль или много
1..* один или много
n Только n (где n > 1)
0..n ноль к n (где n > 1)
1. n один к n (где n > 1)
все эти параметры опциональные, но если вы их укажете, в дальнейшем может значительно улучшить читабельность диаграммы.
Если связь не указана то по умолчанию использует 1 к 1
Bi-directional naviageble association
Bi-directional подразумевает что оба класса осведомлены о свой зависимости к другому классу. Давайте рассмотрим диаграмму
Этот пример показывает что оба класса ShoppingCart и Customer осведомлены о существовании друг друга и таким образом взаимодействуют. Хотя ShoppingCart относиться к Customer и наоборот, они оба могут быть частью чего-то большего.
Обратите внимание на множественное отношение, в примере у покупателя может быть несколько покупательских тележек.
Давайте рассмотрим код приведенной выше диаграммы:
итак нам нужно запомнить что оба класса знают о существовании друг друга
Uni-direction navigable association
в Uni-direction отношении только один класс осведомлён о существовании другого
В этом примере, класс ShoppingCart ничего не знает об классе Customer, но! Customer осведомлен о ShoppingCart и в этом проявляется их отношение. Отметьте что мы оставили множественное значение, подчеркивая что класс Customer знает об множестве ShoppingCart, в то время как само множество ShoppingCart ничего не знает об классе Customer.
Для общности картины, отношение Customer to ShoppingCart может быть диагонально перевернуто, и тогда мы получим вот такую схему:
сейчас единственный класс ShoppingCart относиться ко множеству Customer, без их «виденья». Думаю этот пример Uni-directional должен быть вам знакомым
дайте рассмотрим сам код:
Association class:
Класс ассоциаций, или drop class это класс который показывает специфическую ассоциацию:
пунктирная линия в примере показывает нам что сущность Customer относиться к сущности ShoppingCart и при этом существует сущность WishList, те отношение между Customer и ShoppingCart зависит от существования WishList.
Drop class может принимать любое отношение, включая агрегированную ассоциацию (см след параграф) с любой навигацией.
Круг на зарисовке — опционален.
По традиции, конечно пример кода:
Aggregation (aggregate association)
Агрегирование — показывает что одна сущность является частью другой. Если говорить на простом программерском языке, то это означает что экземпляр сущности наследуется другим через свойства объекта.
Regular aggregation
В обычом агрегированнии цикл жизни сущности зависит от цикла жизни сущностей его образовавших, это и состовляет их отношение. Отмете что ромбообразная форма у края указывает на образующию сущность.
ниже нарисован сценарий, который должерн быть вам довольно знакомым:
Один экземпляр Customer наследует один экземпляр ShoppingCart, в роли currentCart. Однако, Customer
получает существующий объкт ShoppingCart, создавая тем самым зависимость экзепляра ShoppingCart от экземпляра Customer.
давайте рассмотрим код:
Composite Aggregagtion (composition)
В композитивном агрегированнии сам объкт это композиция частей других объектов чей жизненый цикл зависит от жизни самой композиции.
Здесь должна быть строгая связь, в которой целое это композиция его частей:
1. У машины есть колёса, но 4 колеса не состовляют машину
2. Mysql Кластер это композиции mysql серверов, но сам по себе mysql сервер не представляет кластер.
как видно из 2-го примера — у нас должна быть довольно строгая связь. Пользуясь этой связью давай приведем еще один пример:
США это композиция ее штатов:
Возможно все штаты америки не равны США, но здесь мы имеем строгую связь которую требует Composite Aggregation:
США не может сущестовать без своих штатов, машина не может выполнять свои функции без колес, а покупатель не существует без покупательской тележки.
Подумайте про силу связи перед тем как решить проблему зависимости жизненого цикла, а не наоборот:
При моделировании зависимость в жизненый циклах не должна усилять связи.
Если связь слабая — regular aggregation это лучший выбор:
в последствии, при развитии проекта, компоненты могут начать использовать части других компонент, что сведет диаграму на нет если у вас будет сильная жизненая зависимость.
давайте рассмотрим пример на нашей коммерческой системе:
в ней мы решили что ShopppingCart не может сущестовать без Customer (без этого наша система теряет смысл)
Мы так же решили что ShoppingCart это пуп вселенной, по крайней мере для нас, поэтому нам нужно постараться определить остальные объкты через связь с покупательской тележкой:
Результатом нашего решения будет вывод, что покупатель не может существовать без покупательской тележки, а не наоборот,
вы говорите — это магазин, ничего не покупаете — уходите 😛
в чем оптимальный выбор — это остаеться на усмотрение читателя, я же покажу диаграму:
Generalizations
Generalizations — представление кода «как он есть», это связи с которыми вы уже должны были подружиться,( за время програмирования =):
интерфейсы и наследование, я просто приведу вам небольшой пример натации обоих:
асбтракный класс ProductList наследуеться от интерфейса ItemList, ShoppingCart расширяет функциональность ProductList
Dependencies:
Dependencies показывать что изменение в одной структуре может потребовать изменение в другой, во многих случаях другие типы зависимостей уже подразумивают какую-либо зависимость, но есть вы хотите описать зависимости более детально — вы можете использовать dependency, что бы описать связь между эллементами. Это подразумевает что зависимость слабая и не пригодна для использования в associative relation.
давайте посмотрим след диаграмму:
Customer зависит от WishList тк он содержит желаемые предметы покупки. Пунктирная линия показывать что getWishList это статическая операция.
Customer зависит от работы ф-ции getWishList.
В противоречие ассоциации, Dependencies не несут дополнительной смысловой нагрузки и не указываться роли эллементов. При использовании Dependencies так же не обязательно иметь отношения с установленными сущностям (но в этих случаях автор советует использовать ассоицации). Множества не могут быть описаны с помощью зависимостей.
Что бы лучше посмотреть на зависимости — давайте вглянем на наш проект с высоты птичьего полета, будем использовать пакетную диаграмму
Мы видем два пакета: e-commerce и user_management, e-commerce зависит от user_management, для таких страшных вещей как аутентификация и тп.
Эта зависимость кажеться необходимой, но вашей главной задачей при проектировании системы являеться создание как можно меньше такого рода зависимостей между эллеметами а так же создание их взаимозаменяющей возможности. Не забывайте что диаграмма классов не может указать степень зависимости, то её можно принебрень, но не следует от этого отказываться полностью.
Что находится между идеей и кодом? Обзор 14 диаграмм UML
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.
UML представляет собой набор лучших инженерных практик, которые доказали свою эффективность в моделировании больших и сложных систем и является очень важной частью разработки объектно-ориентированного программного обеспечения.
UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.
Происхождение UML
Цель UML — предоставить стандартную нотацию, которая может использоваться всеми объектно-ориентированными методами, а также выбрать и интегрировать лучшие элементы нотаций-предшественников. UML был разработан для широкого спектра приложений. Следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенных систем, анализа, проектирования и развертывания систем).
UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».
На UML также повлияли другие объектно-ориентированные нотации:
Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.
Основные цели дизайна UML:
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.
Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.
Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.
Диаграмма компонентов
На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.
Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.
Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.
Диаграмма развертывания
Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.
Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.
Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.
В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.
Диаграмма объектов
Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.
Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.
Диаграмма пакетов
Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.
Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.
Диаграмма составной структуры
Диаграмма составной структуры аналогична диаграмме классов и является своего рода диаграммой компонентов, используемой в основном при моделировании системы на микроуровне, но она изображает отдельные части вместо целых классов. Это тип статической структурной диаграммы, которая показывает внутреннюю структуру класса и взаимодействия, которые эта структура делает возможными.
Эта диаграмма может включать внутренние части, порты, через которые части взаимодействуют друг с другом или через которые экземпляры класса взаимодействуют с частями и с внешним миром, и соединители между частями или портами. Составная структура — это набор взаимосвязанных элементов, которые взаимодействуют во время выполнения для достижения какой-либо цели. Каждый элемент имеет определенную роль в сотрудничестве.
Диаграмма профилей
Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.
Диаграмма прецедентов
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).
Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.
Диаграмма деятельности
Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.
Диаграмма состояний
Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Диаграмма последовательности
Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.
Диаграмма Коммуникации
Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.
Диаграмма обзора взаимодействия
Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Временная диаграмма
Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути — это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.
Зачем в UML столько диаграмм?
Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.
Все эти люди заинтересованы в различных аспектах системы, и каждый из них требует разного уровня детализации.
Например, кодер должен понимать проект системы и уметь преобразовывать проект в код низкого уровня.
Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.
UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.