uml диаграммы что это
Использование диаграммы классов UML при проектировании и документировании программного обеспечения
Предисловие
Парадигма объектно-ориентированного программирования (далее просто ООП) повсеместно используется при создании современного программного обеспечения. Модель объектов, заложенная в данную парадигму, способна достаточно точно описывать свойства и возможности сущностей реального мира. Разумеется, эти объекты не существуют обособленно друг от друга, они взаимодействуют друг с другом для достижения какой-то глобальной цели разрабатываемой системы.
Стандартная библиотека некоторого языка программирования – замечательный сборник полезных утилит. Однако разнообразие решаемых программистами задач так велико, что одной только стандартной библиотекой ограничиться не получится. Программисту часто приходится самому создавать необходимый ему набор функциональности. Это можно сделать, создав пакет функций или набор классов.
Создание собственных классов при разработке программы добавляет в проект новый уровень абстракции, который позволяет определить некоторый функционал системы и работать в дальнейшем только с ним.
Чем выше уровень абстракции, которым пользуется программист, тем выше уровень его продуктивности при разработке приложения.
Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “spaghetti code”), который будет лишь мешаться, когда вы захотите добавить что-то новое в систему.
Чтобы избежать большинства проблем, возникающих при использовании ООП, нужно:
Иметь некоторый опыт создания программ и использования классов.
Строить структурные диаграммы классов.
Первое придёт со временем, а со вторым я могу вас познакомить прямо сейчас. Сегодня мы разберём диаграмму классов 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.
«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 помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах.
Почему UML?
Впервые UML появился еще в 1990-х годах благодаря трем инженерам-программистам — Грэди Бучу, Ивару Джекобсону и Джеймсу — поскольку они хотели разработать менее хаотичный способ представления разработки все более сложного программного обеспечения, в то же время отделяя методологию от самого процесса. Сегодня UML по-прежнему является стандартной практической нотацией для разработчиков, а также для руководителей проектов, владельцев бизнеса, технических предпринимателей и специалистов из разных отраслей.
Каковы преимущества UML?
Типы диаграмм UML
Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей.
От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.
Пример базовой диаграммы последовательности UML. Шаблон доступен длязагрузки
Давайте посмотрим внимательнее:
Структурные диаграммы
Структурные диаграммы представляют статическую структуру программного обеспечения или системы, они также показывают различные уровни абстракции и реализации. Они используются, чтобы помочь визуализировать различные структуры, составляющие систему, например, базу данных или приложение. Они показывают иерархию компонентов или модулей и то, как они связаны и взаимодействуют между собой. Эти инструменты обеспечивают руководство работы и гарантируют, что все части системы функционируют так, как задумано по отношению ко всем остальным частям.
Поведенческие диаграммы
Основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса. Эти диаграммы показывают функциональные возможности системы и демонстрируют, что должно происходить в моделируемой системе.
Давайте подробнее рассмотрим различные типы диаграмм UML, которые относятся к каждой категории:
1. Структурные диаграммы UML
2. Поведенческие диаграммы UML
Модели базы данных
UML также завоевывает популярность как нотация для моделирования баз данных. Эти модели являются отличным визуальным инструментом для проведения мозгового штурма, создания диаграмм в свободной форме и совместной работы над идеями.
Хотя UML не имеет спецификаций для моделирования данных, он может быть полезным инструментом для построения диаграмм, тем более что данные из баз данных могут использоваться в объектно-ориентированном программировании.
Давайте рассмотрим различные типы моделей баз данных, которые вы можете создать:
Упрощение с помощью программного обеспечения
Создаете ли вы модели баз данных или диаграммы UML, использование программных инструментов упрощает и улучшает этот процесс. Обязательно выберите инструменты, которые позволят вам:
При разработке программного обеспечения и непрограммируемых систем во многих отраслях использование визуальных UML-диаграмм может играть важную роль в построении поведенческих процессов и структур. Узнайте больше о создании диаграмм UML с помощью программного обеспечения при помощи пошаговой инструкции: руководства.
Сведения об авторе
Что находится между идеей и кодом? Обзор 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.