Унифицированный язык моделирования — это стандартизированный язык моделирования общего назначения, которым в настоящее время фактически управляет отраслевой стандарт Группа управления объектами (OMG) . UML включает в себя набор методов графической записи для создания визуальных моделей для систем с интенсивным использованием программного обеспечения.
В UML 2.2 существует 14 типов диаграмм UML, которые делятся на две категории:
- 7 типов диаграмм представляют структурную информацию
- Еще 7 представляют общие типы диаграмм UML для моделирования поведения, включая четыре, которые представляют различные аспекты взаимодействия.
Эти диаграммы можно классифицировать иерархически, как показано на следующей карте диаграммы UML:
Вопрос: UML огромен и сложен?
UML — это действительно огромная тема. UML предоставляет большой объем нотаций для построения диаграмм, сгруппированных в 14 различных типов диаграмм UML, каждая из которых имеет разные модели UML, предназначенные для разных целей и отвечающие различным аспектам потребностей разработки.
- Каждая диаграмма UML из 14 типов диаграмм UML предоставляет большой набор конструкций и обозначений, которые охватывают различные потребности для большинства проектов разработки программного обеспечения.
- Спецификация UML насчитывает более 700 страниц и явно считается слишком сложной и отрицательно влияет на восприятие и принятие UML.
- Как правило, пользователи склонны рассматривать и использовать только часть своих диаграмм/конструкций UML.
Ответ: изучите наиболее важные диаграммы и нотации UML.
Грэди Буч, один из самых важных разработчиков унифицированного языка моделирования, заявил, что «для 80% всего программного обеспечения требуется только 20% UML».
Что такое состояния UML Survey*?
Мы могли бы интерпретировать результаты опроса UML, предположив, что если диаграмма
- широко используется, если он ≥ 60% источников
- редко используется, если он составляет ≤ 40% источников
В этой статье я представляю все 14 типов диаграмм UML в соответствии с упомянутым выше порядком частоты их использования:
Например, диаграмма классов является наиболее широко используемой, поэтому она будет обсуждаться первой в этом разделе и так далее…
Диаграмма классов
В разработке программного обеспечения диаграмма классов на унифицированном языке моделирования (UML) представляет собой тип диаграммы статической структуры, которая описывает структуру системы, показывая классы системы, их атрибуты, операции (или методы) и отношения между объектами.
Назначение диаграмм классов
- Показывает статическую структуру классификаторов в системе
- Диаграмма обеспечивает базовую нотацию для других структурных диаграмм, предписанных UML.
- Полезно для разработчиков и других членов команды.
- Бизнес-аналитики могут использовать диаграммы классов для моделирования систем с точки зрения бизнеса.
Диаграмма классов UML состоит из:
- Набор классов и
- Набор отношений между классами
Диаграмма классов — пример инструмента диаграммы
Диаграмма классов может также иметь примечания, прикрепленные к классам или отношениям. Примечания отображаются серым цветом.
В приведенном выше примере:
Мы можем интерпретировать значение приведенной выше диаграммы классов, прочитав пункты следующим образом.
- Форма — это абстрактный класс. Он показан курсивом.
- Форма — это суперкласс. Круг, прямоугольник и многоугольник являются производными от формы. Другими словами, Круг — это Форма. Это отношение обобщения/наследования.
- Существует связь между DialogBox и DataController.
- Форма является частью окна. Это отношения агрегации. Shape может существовать без Window.
- Точка является частью Круга. Это композиционные отношения. Точка не может существовать без Окружности.
- Окно зависит от события. Однако Event не зависит от Window.
- Атрибутами Circle являются радиус и центр. Это класс сущности.
- Имена методов Circle: area(),circ(), setCenter() и setRadius().
- Радиус параметра в Circle является параметром in типа float.
- Метод area() класса Circle возвращает значение типа double.
- Атрибуты и имена методов Rectangle скрыты. У некоторых других классов на диаграмме также скрыты атрибуты и имена методов.
Вторым по популярности типом диаграмм в UML является диаграмма деятельности:
Диаграмма деятельности
Диаграмма действий — еще одна важная поведенческая диаграмма в диаграмме UML для описания динамических аспектов системы. Диаграмма действий, по сути, представляет собой расширенную версию блок-схемы, которая моделирует поток от одного действия к другому.
Когда использовать диаграмму деятельности
Диаграммы действий описывают, как действия координируются для предоставления услуги, которая может находиться на разных уровнях абстракции. Как правило, событие должно быть достигнуто некоторыми операциями, особенно когда операция предназначена для достижения ряда различных целей, требующих координации, или того, как события в одном варианте использования соотносятся друг с другом, в частности, в случаях использования, когда действия могут пересекаться и требовать координации. Он также подходит для моделирования того, как набор вариантов использования координируется для представления бизнес-процессов.
- Выявление возможных вариантов использования путем изучения бизнес-процессов
- Определите предварительные и последующие условия (контекст) для вариантов использования.
- Моделирование рабочих процессов между/внутри вариантов использования
- Моделирование сложных рабочих процессов в операциях над объектами
- Подробное моделирование сложных действий на высокоуровневой диаграмме действий
Диаграмма активности — учитесь на примерах
Базовая диаграмма деятельности — блок-схема вроде
Пример диаграммы действий — технологический заказ
Учитывая описание проблемы, связанное с рабочим процессом обработки заказа, смоделируем описание в визуальном представлении с помощью диаграммы действий:
Технологический заказ — описание проблемы
Как только заказ получен, действия разбиваются на два параллельных набора действий. Одна сторона заполняет и отправляет заказ, а другая занимается выставлением счетов.
На стороне Fill Order способ доставки определяется условно. В зависимости от условия выполняется операция «Ночная доставка» или «Обычная доставка».
Наконец, параллельные действия объединяются, чтобы закрыть заказ.
Пример диаграммы деятельности ниже визуализирует поток в графической форме.
Третьим наиболее широко используемым типом диаграммы UML является диаграмма последовательности:
Диаграмма последовательности
Диаграммы последовательностей UML — это диаграммы взаимодействия, в которых подробно описывается, как выполняются операции. Они фиксируют взаимодействие между объектами в контексте сотрудничества. Диаграммы последовательности ориентированы на время и визуально показывают порядок взаимодействия, используя вертикальную ось диаграммы для представления времени, когда и какие сообщения отправляются.
Пример диаграммы последовательности действий: гостиничная система
Sequence Diagram — это диаграмма взаимодействия, которая подробно описывает, как выполняются операции — какие сообщения отправляются и когда. Диаграммы последовательности организованы по времени. Время идет по мере того, как вы спускаетесь по странице. Объекты, участвующие в операции, перечислены слева направо в зависимости от того, когда они участвуют в последовательности сообщений.
Ниже представлена схема последовательности действий при бронировании отеля. Объектом, инициирующим последовательность сообщений, является окно резервирования.
Обратите внимание: диаграммы классов и объектов представляют собой представления статической модели. Диаграммы взаимодействия являются динамическими. Они описывают, как объекты взаимодействуют.
Четвертыми наиболее широко используемыми типами диаграмм UML (96%) являются:
- диаграмма вариантов использования
- диаграмма конечного автомата
Диаграмма варианта использования
Диаграмма вариантов использования UML — это основная форма требований к системе/программному обеспечению для новой недостаточно разработанной программы. Варианты использования определяют ожидаемое поведение (что), а не точный метод его реализации (как).
Когда варианты использования определены, их можно обозначить как текстовым, так и визуальным представлением (т. е. диаграммой вариантов использования). Ключевой концепцией моделирования вариантов использования является то, что оно помогает нам проектировать систему с точки зрения конечного пользователя. Это эффективный метод сообщения о поведении системы с точки зрения пользователя путем указания всего поведения системы, видимого извне.
Краткий обзор диаграммы вариантов использования
Стандартная форма диаграммы вариантов использования определена в унифицированном языке моделирования, как показано в примере диаграммы вариантов использования ниже:
Диаграмма вариантов использования — Системы продажи автомобилей
На рисунке ниже показан пример схемы вариантов использования для автомобильной системы. Как видите, даже такая большая система, как система продажи автомобилей, содержит не более 10 вариантов использования! В этом прелесть моделирования вариантов использования.
Модель вариантов использования также показывает использование расширений и включений. Кроме того, существуют ассоциации, связывающие акторов и варианты использования.
Диаграмма состояний
Поведение объекта является не только прямым следствием его входных данных, но также зависит от его предшествующего состояния. Прошлую историю объекта лучше всего можно смоделировать с помощью диаграммы конечного автомата или традиционно называемого автоматом.
Диаграммы конечного автомата UML (или иногда называемые диаграммой состояний, автоматом состояний или диаграммой состояний) показывают различные состояния объекта. Диаграммы конечного автомата также могут показать, как объект реагирует на различные события, переходя из одного состояния в другое. Диаграмма конечного автомата — это диаграмма UML, используемая для моделирования динамической природы системы.
Обозначение простой диаграммы состояний
Простое состояние — это состояние, не имеющее подструктуры. Состояние, которое имеет подсостояния (вложенные состояния), называется составным состоянием. Подсостояния могут быть вложены на любом уровне. Вложенный конечный автомат может иметь не более одного начального состояния и одного конечного состояния. Подсостояния используются для упрощения сложных плоских автоматов состояний, показывая, что некоторые состояния возможны только в определенном контексте (окружающее состояние).
Пример подсостояния — обогреватель
История государств
Если не указано иное, когда переход входит в составное состояние, действие вложенного конечного автомата начинается снова с начального состояния (если только переход не нацелен непосредственно на подсостояние). Состояния истории позволяют автомату повторно войти в последнее подсостояние, которое было активным перед выходом из составного состояния. Пример использования состояния истории представлен на рисунке ниже.
Согласно опросу, использование Communication Diagram составляет 82%:
Диаграмма связи
Диаграммы связи UML , как и диаграммы последовательности — своего рода диаграммы взаимодействия, показывают, как взаимодействуют объекты. Диаграмма связи — это расширение диаграммы объектов, которое показывает объекты вместе с сообщениями, которые передаются от одного к другому. В дополнение к ассоциациям между объектами диаграмма связи показывает сообщения, которые объекты посылают друг другу.
Диаграмма связи с первого взгляда
В примере нотации для коммуникационной диаграммы объекты (действующие лица в вариантах использования) представлены прямоугольниками. В примере (общая схема связи):
- Объектами являются Объект1, Объект2, Объект…, ОбъектN-1… и ОбъектN.
- Сообщения, передаваемые между объектами, представлены помеченными стрелками, которые начинаются с объекта-отправителя (актора) и заканчиваются объектом-получателем.
- Примеры сообщений, передаваемых между объектами, помечаются 1: сообщение1, 2: сообщение2, 3: сообщение3 и т. д., где числовой префикс имени сообщения указывает его порядок в последовательности.
- Сначала Объект1 отправляет Объекту2 сообщение message1, Объект2, в свою очередь, отправляет ОбъектуN-1 сообщение message2 и так далее.
- Сообщения, которые объекты отправляют сами себе, обозначаются как циклы (например, сообщение message5).
Диаграмма связи и диаграмма последовательности
Диаграмма связи и диаграмма последовательности аналогичны. Они семантически эквивалентны, то есть представляют одну и ту же информацию, и вы можете превратить сообщение в диаграмму последовательности и наоборот. Основное различие между ними состоит в том, что на диаграмме связи элементы располагаются по пространству, а на диаграмме последовательности — по времени.
Из двух типов диаграмм взаимодействия диаграммы последовательности используются гораздо чаще, чем диаграммы связи. Итак, зачем вам использовать диаграммы связи? Прежде всего, они очень полезны для визуализации отношений между объектами, взаимодействующими для выполнения конкретной задачи. Это трудно определить по диаграмме последовательности. Кроме того, диаграммы связи также могут помочь вам определить точность вашей статической модели (например, диаграммы классов).
Использование диаграммы компонентов и диаграммы развертывания составляет 80%:
Диаграмма компонентов
Диаграммы компонентов UML используются при моделировании физических аспектов объектно-ориентированных систем, которые используются для визуализации, спецификации и документирования систем на основе компонентов, а также для создания исполняемых систем путем прямого и обратного проектирования.
Диаграммы компонентов — это, по сути, диаграммы классов, которые фокусируются на компонентах системы, которые часто используются для моделирования статического представления реализации системы.
Краткий обзор схемы компонентов
Диаграмма компонентов разбивает реальную разрабатываемую систему на различные уровни функциональности. Каждый компонент отвечает за одну четкую цель во всей системе и взаимодействует с другими важными элементами только по мере необходимости.
Схема развертывания
Диаграмма развертывания UML — это диаграмма, которая показывает конфигурацию узлов обработки во время выполнения и компонентов, которые находятся на них. Диаграммы развертывания — это своего рода структурная диаграмма, используемая при моделировании физических аспектов объектно-ориентированной системы. Они часто используются для моделирования статического представления развертывания системы (топологии оборудования).
Краткий обзор схемы развертывания
Диаграммы развертывания важны для визуализации, спецификации и документирования встроенных, клиент-серверных и распределенных систем, а также для управления исполняемыми системами путем прямого и обратного проектирования.
Диаграмма развертывания — это особый вид диаграммы классов, который фокусируется на узлах системы. Графически диаграмма развертывания представляет собой набор вершин и дуг. Диаграммы развертывания обычно содержат:
Узлы
- Трехмерный блок представляет собой узел, программный или аппаратный.
- Узел HW может быть обозначен <<стереотипом>>
- Соединения между узлами представлены линией с необязательным <<стереотипом>>.
- Узлы могут находиться внутри узла
Другие обозначения
- Зависимость
- Ассоциативные отношения.
- Может также содержать примечания и ограничения.
Согласно опросу, использование диаграммы объектов UML составляет 71%:
Диаграмма объекта
Объект — это экземпляр определенного момента времени выполнения, включая объекты и значения данных. Статическая диаграмма объектов UML является экземпляром диаграммы классов ; он показывает снимок подробного состояния системы в определенный момент времени, поэтому диаграмма объектов охватывает объекты и их отношения в определенный момент времени.
Диаграмма объекта с первого взгляда
Диаграмма объектов показывает эту связь между созданными классами и определенным классом, а также связь между этими объектами в системе. Они полезны для объяснения небольших частей вашей системы, когда диаграмма классов вашей системы очень сложна, а также иногда для моделирования рекурсивных отношений на диаграмме.
Лучший способ проиллюстрировать, как выглядит диаграмма объектов, — показать диаграмму объектов, полученную из соответствующей диаграммы классов.
Следующая система управления заказами показывает их взаимосвязь. Эта небольшая диаграмма классов показывает, что кафедра университета может содержать множество других кафедр, а диаграмма объектов ниже создает экземпляр диаграммы классов, заменяя ее конкретным примером.
Пример диаграммы класса к объекту — система заказов
Использование диаграммы пакета составляет 70%:
Схема пакета
Диаграмма пакета, своего рода структурная схема, показывает расположение и организацию элементов модели в проекте среднего и крупного масштаба. Диаграмма пакетов может отображать как структуру, так и зависимости между подсистемами или модулями, показывая различные виды системы, например, как многоуровневое (также известное как многоуровневое) приложение — модель многоуровневого приложения.
Краткий обзор схемы упаковки
Диаграмма пакетов используется для упрощения сложных диаграмм классов, вы можете группировать классы в пакеты. Пакет — это набор логически связанных элементов UML.
На диаграмме ниже представлена бизнес-модель, в которой классы сгруппированы в пакеты:
- Пакеты отображаются в виде прямоугольников с небольшими вкладками вверху.
- Имя пакета находится на вкладке или внутри прямоугольника.
- Пунктирные стрелки — зависимости.
- Один пакет зависит от другого, если изменения в другом могут вызвать изменения в первом.
Использование диаграммы составной структуры составляет 52%:
Схема составной структуры
Composite Structure Diagram — один из новых артефактов, добавленных в UML 2.0. Составная структурная диаграмма — это структурная диаграмма UML, содержащая классы, интерфейсы, пакеты и их взаимосвязи и обеспечивающая логическое представление всей программной системы или ее части. Он показывает внутреннюю структуру (включая части и соединители) структурированного классификатора или сотрудничества.
Составная структурная диаграмма выполняет ту же роль, что и диаграмма классов, но позволяет более подробно описать внутреннюю структуру нескольких классов и показать взаимодействие между ними. Вы можете графически представить внутренние классы и части и показать связи как между классами, так и внутри них.
Краткий обзор диаграммы составной структуры
- Диаграммы составной структуры показывают внутренние части класса.
- Части имеют имена: partName:partType[множественность]
- Агрегированные классы являются частями класса, но части не обязательно являются классами, часть — это любой элемент, который используется для создания содержащего класса.
Временная диаграмма используется только на 40% и редко используется обычными пользователями.
Временная диаграмма
Временные диаграммы — это диаграммы взаимодействия UML , используемые для отображения взаимодействий, когда основная цель диаграммы — рассуждать о времени. Они сосредоточены на изменении условий внутри и между линиями жизни вдоль линейной оси времени. Временные диаграммы описывают поведение как отдельных классификаторов, так и взаимодействия классификаторов, акцентируя внимание на времени возникновения событий, вызывающих изменения в смоделированных условиях Lifelines.
Краткий обзор временной диаграммы
Представление временной шкалы состояния
Переходы из одного состояния в другое представлены изменением уровня линии жизни . В течение периода времени, когда объект находится в заданном состоянии, временная шкала проходит параллельно этому состоянию. Изменение состояния проявляется как вертикальное изменение с одного уровня на другой. Причиной изменения, как и в случае с диаграммой состояний или последовательностей, является получение сообщения, событие, вызывающее изменение, состояние в системе или даже просто течение времени.
Жизненная линия ценности Представление
На рисунке ниже показана альтернативная запись временной диаграммы UML. Он показывает состояние объекта между двумя горизонтальными линиями, которые пересекаются друг с другом при каждом изменении состояния.
Интерактивная обзорная диаграмма — это новая диаграмма, добавленная в UML 2.0:
Интерактивная обзорная диаграмма
Обзор взаимодействия UML Диаграммы обеспечивают высокий уровень абстракции модели взаимодействия. Это вариант диаграммы активности, где узлы представляют собой взаимодействия или случаи взаимодействия.
Диаграмма обзора взаимодействия фокусируется на обзоре потока управления взаимодействиями, которые также могут отображать поток действий между диаграммами. Другими словами, вы можете связать «настоящие» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Краткий обзор диаграммы взаимодействия
Обзорная диаграмма взаимодействия — это один из четырнадцати типов диаграмм унифицированного языка моделирования (UML), который может отображать поток управления с узлами, которые могут содержать диаграммы взаимодействия, которые показывают, как набор фрагментов может быть инициирован в различных сценариях. Диаграммы обзора взаимодействия сосредоточены на обзоре потока управления, где узлами являются взаимодействия (sd) или использование взаимодействия (ref).
Другие элементы обозначений для диаграмм обзора взаимодействия такие же, как и для диаграмм действий и диаграмм последовательности. К ним относятся начальные, окончательные узлы, решения, слияния, разветвления и соединения.
Диаграмма UML с наименьшим использованием — это диаграмма профиля, она набрала всего 11%:
Диаграмма профиля
Являясь языком моделирования общего назначения, UML обеспечивает стабильную основу для широкого спектра требований. Он не определен для конкретных областей приложений или какой-либо конкретной технологии. Однако в некоторых случаях UML является слишком общим, и его использование требует значительных усилий. В таких случаях выгодно использовать язык, оптимизированный для данной предметной области и предлагающий специальные концепции.
Диаграмма профиля, своего рода структурная диаграмма в унифицированном языке моделирования (UML), предоставляет общий механизм расширения для настройки моделей UML для определенных доменов и платформ. Механизмы расширения позволяют уточнять стандартную семантику строго аддитивным образом, предотвращая ее противоречие со стандартной семантикой. Профили определяются с использованием стереотипов , определений теговых значений и ограничений , которые применяются к определенным элементам модели, таким как классы, атрибуты, операции и действия. Профиль — это набор таких расширений, которые совместно настраивают UML для конкретной области (например, аэрокосмической, медицинской, финансовой) или платформы (J2EE, .NET).
Пример диаграммы профиля — управление ИТ
Профиль применяется к другому пакету, чтобы сделать стереотипы в профиле доступными для этого пакета. На приведенном ниже рисунке показаны профили сети, телекоммуникаций и программного обеспечения, применяемые к пакету ITManagement.
Ищете бесплатный онлайн-инструмент для разработки программного обеспечения?
Вот репозиторий Visual Paradigm Online для примеров дизайна программного обеспечения, это:
- Бесплатно (для личных и некоммерческих целей)
- Онлайн (нулевая установка и настройка)
- Поддержка Google Диска и бесплатного облачного хранилища
- Много примеров
- Используйте его в любое время и в любом месте! нужен только веб-браузер
Диаграмма варианта использования
Диаграмма классов
Диаграмма деятельности
Диаграмма компонентов
Схема развертывания
Схема пакета
Диаграмма конечного автомата
Диаграмма последовательности
ER-диаграмма
Диаграмма потока данных
Диаграмма устойчивости
Предприятие Интерн. Ptrns
Диаграмма требований
Диаграмма определения блока
Параметрическая диаграмма
Внутренняя блок-схема
Диаграмма Гейна Сарсона
Йордон и Коуд
Юрдон ДеМарко DFD
ССДМ ДФД
Аве Кодер!
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.
UML представляет собой набор лучших инженерных практик, которые доказали свою эффективность в моделировании больших и сложных систем и является очень важной частью разработки объектно-ориентированного программного обеспечения.
UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.
Происхождение UML
Цель UML — предоставить стандартную нотацию, которая может использоваться всеми объектно-ориентированными методами, а также выбрать и интегрировать лучшие элементы нотаций-предшественников. UML был разработан для широкого спектра приложений. Следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенных систем, анализа, проектирования и развертывания систем).
UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
- Техника объектного моделирования OMT [James Rumbaugh 1991], которая была лучшей для анализа информационных систем с большим объемом данных.
- Booch [Grady Booch 1994] — отлично подходит для разработки и реализации. Грэди Буч много работал с языком Ада и был крупным игроком в разработке объектно-ориентированных методов для языка. Хотя метод Буча был сильным, нотация была воспринята менее хорошо, например, в его моделях преобладали формы облаков, что выглядело не очень аккуратно.
- OOSE (объектно-ориентированная программная инженерия [Ivar Jacobson 1992]) — модель, известная как модель прецедентов — это мощная методология для понимания поведения всей системы, область, где ООП традиционно была слабой.
В 1994 году Джим Рамбо, не путать с Джоном Рэмбо, хотя Джим тоже был крут, потому что был, на секундочку, создателем вышеупомянутой техники объектного моделирования, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Цель партнерства состояла в том, чтобы объединить их идеи в единый унифицированный метод (рабочее название для метода действительно было — «Единый метод»).
К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».
На UML также повлияли другие объектно-ориентированные нотации:
- Меллор и Шлаер [1998]
- Coad и Yourdon [1995]
- Вирфс-Брок [1990]
- Мартин и Оделл [1992]
UML также включает в себя новые концепции, которых в то время не было в других основных методах, таких как механизмы расширения и язык ограничений.
Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.
Основные цели дизайна UML:
- Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями.
- Обеспечить механизмы расширяемости и специализации для расширения основных понятий.
- Быть независимым от конкретных языков программирования и процессов разработки.
- Обеспечить формальную основу для понимания языка моделирования.
- Поощрять рост рынка объектно-ориентированных инструментов.
- Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
- Интегрировать лучшие практики.
Диаграммы UML подразделяют на два типа — это структурные диаграммы и диаграммы поведения.
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
- Диаграмма составной структуры
- Диаграмма развертывания
- Диаграмма пакетов
- Диаграмма профилей
- Диаграмма классов
- Диаграмма объектов
- Диаграмма компонентов
Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:
- Диаграмма деятельности
- Диаграмма прецедентов
- Диаграмма состояний
- Диаграмма последовательности
- Диаграмма коммуникаций
- Диаграмма обзора взаимодействия
- Временная диаграмма
Теперь пару слов о каждой из них
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.
Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.
Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.
Диаграмма компонентов
На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.
Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.
Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.
Диаграмма развертывания
Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.
Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.
Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.
В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.
Диаграмма объектов
Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.
Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.
Диаграмма пакетов
Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.
Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.
Диаграмма составной структуры
Диаграмма составной структуры аналогична диаграмме классов и является своего рода диаграммой компонентов, используемой в основном при моделировании системы на микроуровне, но она изображает отдельные части вместо целых классов. Это тип статической структурной диаграммы, которая показывает внутреннюю структуру класса и взаимодействия, которые эта структура делает возможными.
Эта диаграмма может включать внутренние части, порты, через которые части взаимодействуют друг с другом или через которые экземпляры класса взаимодействуют с частями и с внешним миром, и соединители между частями или портами. Составная структура — это набор взаимосвязанных элементов, которые взаимодействуют во время выполнения для достижения какой-либо цели. Каждый элемент имеет определенную роль в сотрудничестве.
Диаграмма профилей
Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.
Диаграмма прецедентов
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).
Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.
Диаграмма деятельности
Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.
Диаграмма состояний
Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Диаграмма последовательности
Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.
Диаграмма Коммуникации
Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.
Диаграмма обзора взаимодействия
Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Временная диаграмма
Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути — это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.
Зачем в UML столько диаграмм?
Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.
Все эти люди заинтересованы в различных аспектах системы, и каждый из них требует разного уровня детализации.
Например, кодер должен понимать проект системы и уметь преобразовывать проект в код низкого уровня.
Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.
UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.
Для тех, кому лень читать:
Аве!
1. Введение.
UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.
В этом документе описаны самые основные разделы языка UML, которые потребуются в повседневной работе.
2. Основы.
UML представляет собой графическую нотацию которая предназначена для моделирования и описания всех процессов протекающих в процессе разработки. Основу UML представляют диаграммы, которые различаются по типам и предназначены для моделирования различных аспектов разработки.
Все диаграммы можно условно разделить на поведенческие и структурные. Поведенческие диаграммы отображают процессы, протекающие в моделируемой среде. Структурные диаграммы отображают элементы, из которых состоит система. При этом одни и те же типы диаграмм могут использоваться как для моделирования бизнес-процессов, так и для непосредственного проектирования архитектуры.
3. Описание типов диаграмм.
3.1. Диаграмма вариантов использования (Use—case diagram).
Диаграмма вариантов использования является отправной точкой в процессе моделирования. Она предназначена для описания взаимодействия проектируемой системы с любыми внешними или внутренними объектами — пользователями, другими системами и т.п.
Основными понятиями при работе с диаграммой вариантов использования являются Актор (Actor) и Вариант использования (Use case).
Актор – это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой.
Проектирование диаграммы вариантов использования начинается с определения списка Акторов. На диаграммах Актор обозначается следующим значком:
Каждый Актор обладает уникальным именем.
Друг с другом акторы могут быть связаны различного рода отношениями.
Например, акторы могут наследоваться друг от друга.
Это означает, что акторы-наследники наследуют характеристики базовых акторов.
Следующим этапом после определения списка акторов является определение списка вариантов использования.
Вариант использования – это конечная единица взаимодействия актора и системы. Совокупность всех вариантов использования полностью определяет поведение системы.
Вариант использования обозначается значком:
Каждый вариант использования относится к каком-либо актору. Такое отношение обозначает, что данный актор инициирует данный вариант использования.
Например:
означает, что актор User инициирует вариант использования Login.
Один и тот же вариант использования может использоваться несколькими акторами, например:
вариант использования Login используется двумя акторами.
Варианты использования также могут быть связаны друг с другом различными отношениями.
1. «Включение» одного варианта использования в другой. Означает, что один вариант использования инициируется в процессе другого. Например:
2. «Расширение». Означает, что один вариант использования является дополнением или уточнением другого варианта использования в случае наступления некоторых условий. Например:
3. «Реализация». Означает, что один вариант использования является реализацией другого варианта использования. Например, если один из них описан в терминах бизнес-процессов, а другой – в терминах проектируемой системы.
Например:
Кроме того, варианты использования могут быть связаны отношением «Реализация» с требованиями к системе и с классами. При наличии таких связей есть возможность проследить в каких классах реализованы требования и какие классы могут быть затронуты при изменении требований или вариантов использования.
Например:
Кроме Акторов и Вариантов использования на диаграмме также могут находиться следующие элементы:
“Collaboration” – элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их совместной работы.
Обозначается значком
Например,
«Boundary» — элемент, предназначенный для визуальной группировки объектов – акторов и вариантов использования – по принципу их распределения на подсистемы или компоненты.
Обозначается значком
Например:
Среди акторов могут быть не только пользователи, но и внешние системы и внутренние подсистемы.
Пример внутренней подсистемы:
3.2. Диаграмма последовательностей (Sequence diagram)
Диаграмма последовательностей служит основным способом расшифровки последовательности действий в процессе выполнения того или иного варианта использования.
Иными словами, если вариант использования отвечает на вопрос «Что делает актор?», то последовательность отвечает на вопрос «Как работает система при выполнении данного варианта использования?».
Таким образом, диаграмма последовательностей всегда создается в привязке к варианту использования. Каждый вариант использования может содержать несколько диаграмм последовательностей, на тот случай, если они описывают несколько альтернативных вариантов развития событий.
Диаграмма последовательностей, так же, как и вариант использования, может быть реализована как в терминах бизнес-объектов, так и в терминах физических сущностей, таких как компоненты или классы.
Проще всего продемонстрировать суть диаграммы последовательностей на примере:
Диаграмма последовательностей всегда начинается с актора, инициирующего процесс. Вверху диаграммы располагаются элементы, классы или компоненты, которые задействованы в процессе работы.
На самой диаграмме показаны линии жизни каждого из объектов и процесс их взаимодействия.
Взаимодействие объектов показано стрелками. В терминах диаграмм последовательностей такое взаимодействия называется Сообщение (Message) В приведенном примере под сообщением понимается вызов методов тех или иных классов. При этом, как видно на примере, сообщения могут быть вложены друг в друга, что означает, что один метод вызывается в теле другого.
Кроме сообщений, которые вызываются другими объектами, существуют собственные сообщения, которые объект вызывает сам у себя (Self—message).
Например:
Кроме того, существуют также обратные сообщения (Return message), которые обозначают передачу некоторой информации вызывающему сообщению. В терминах классов это означает возврат некоторого значения.
Например:
На этой диаграмме метод возвращает результаты своей работы.
Собственные сообщения также могут быть обратными.
Таким образом, к основным объектам диаграмм последовательностей относятся акторы, объекты-участники процесса, линии жизни и сообщения.
Сообщения могут объединяться в комбинированные фрагменты (Combined fragment), который предназначен для отображения циклов, ветвлений, критических секций и пр.
Пример ветвления:
Пример цикла:
Некоторые сообщения могут заканчиваться Конечными точками (End point), которые означают выход из алгоритма.
Пример:
В качестве участника диаграммы могут выступать не только классы, но и любые другие объекты – например, варианты использования в тех случаях, когда есть необходимость продемонстрировать включение или расширение.
Например:
3.3. Диаграмма классов
В отличие от двух предыдущих поведенческих диаграмм, диаграмма классов носит структурный характер. Она предназначена для отображения классов разрабатываемого приложения и их взаимосвязей.
Так же как и предыдущие диаграммы она может быть представлена как в терминах конкретных классов, так и в терминах бизнес-объектов.
Диаграммы классов обычно заполняются параллельно с диаграммами последовательностей в процессе моделирования работы вариантов использования.
Основным элементом диаграммы классов является класс.
Обозначается значком:
Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции — в терминах UML).
Абстрактные классы отличаются наклонным написанием заголовка:
Под атрибутами класса в терминологии UML понимают его поля.
Атрибуты записываются с указанием доступности, имени и типа.
Например:
Знак «-» означает, что атрибут является приватным (private).
Знак «+» означает, что атрибут является публичным (public).
Знак «#» означает, что атрибут является защищенным(protected).
После имени следует указание типа атрибута.
Под операциями в терминологии UML понимаются методы, свойства, индексаторы и пр.
Операции также записываются с указанием области видимости, имени и возвращаемого типа. Однако для них также указывается перечень принимаемых значений.
Например:
Статические атрибуты и операции записываются с подчеркиванием, например:
Абстрактные методы записываются наклонным шрифтом, например:
Кроме классов, важным элементом диаграмм классов являются интерфейсы.
Интерфейс обозначается так:
Кроме классов и интерфейсов на диаграмме классов также могут помещаться перечисления.
Перечисление обозначается так:
Обычно перечисление указывается с перечнем возможных значений, например:
На диаграмме классов отображаются не только классы, интерфейсы и пр., но и их взаимосвязи.
Взаимосвязи бывают различных типов и отображаются, соответственно, по-разному.
Генерализация или наследование (Generalize) обозначается так:
На примере показано, что два класса являются наследниками абстрактного класса.
Реализация (Realize) – означает, что данный класс реализует данный интерфейс:
Ассоциация (Associate). Наиболее широко используемая связь между классами. Она имеет достаточно широкое значение и может означать, например, следующее:
1. Один класс осуществляет взаимодействие с другим каким-либо образом.
Например:
2. Один класс включает в себя экземпляр другого класса.
Например:
Видим, что перечисление Status включено в класс User, при этом имя поля Status, с областью видимости public.
3. Один класс включает в себя несколько экземпляров другого класса.
Например:
Видим, что коллекция UsersCollection может включать от нуля до бесконечности объектов User.
Возможные значения количества объектов:
· «*» или «0..*» — любое количество объектов
· «0..n» — любое количество объектов, но не больше n, например «0..5»
· «n» — точное количество объектов, например «1», «5»
· «n..*» — любое количество объектов, но не меньше n, например«1..*» — хотя бы один.
Если Ассоциация не может быть реализована без дополнительных классов (например, отношение «многие-ко-многим»), то она реализуется при помощи дополнительных классов ассоциации, которые предназначены решить эту задачу.
Обозначается это следующим образом:
В данном примере вы видите, что для того, чтобы установить связь «многие-ко-многим» между переводчиками (класс Translator) и языками (класс Language) используется вспомогательный класс TranslatorToLanguage.
Композиция (Compose) — означает, что объекты одного класса могут быть включены в объекты другого класса и при этом этот вложенный объект может находиться только в одном объекте-контейнере. Если объект контейнер удаляется, то вложенный объект тоже удаляется.
Например:
Агрегация (Aggregate) — означает, что объекты одного класса могут быть включены в объекты другого класса и при этом этот вложенный объект может находиться в нескольких объектах-контейнерах. Если объект контейнер удаляется, то вложенный объект не удаляется.
Например:
Для большей наглядности кроме стандартного значка класса, есть также дополнительные значки, которые применяются для некоторых типов классов. Я привел здесь три наиболее часто используемых обозначения, которые применяются для работы с шаблоном «Модель-Представление-Контроллер»
1. Класс-сущность (Entity) – обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах.
Обозначается:
2. Класс-контроллер (Controller) – обычно используется для классов, которые используются для выполнения некоторых операций над объектами.
Обозначается:
3. Класс-Разграничитель (Boundary) – обычно используется для классов, отделяющих внутреннюю структуру системы от внешней среды. Это могут быть WebServices, пользовательский интерфейс и пр.
Обозначается:
3.4. Диаграмма коммуникаций
Данный тип диаграмм также относится к поведенческим диаграммам и предназначен для описания коммуникаций между элементами системы. Диаграмма коммуникаций позволяет наглядно представить какие элементы системы задействованы при выполнении некоторой задачи и каким образом организовано их взаимодействие.
Диаграмма коммуникаций, так же как и диаграмма последовательностей, обычно создается в привязке в варианту использования, который она описывает. Отличие от диаграммы последовательностей состоит в том, что диаграмма коммуникаций предназначена для отображения взаимодействия между инстанцированными объектами, в то время как диаграмма последовательностей описывает функционирование и структуру классов.
Обозначения, которые используются для отображения объектов на диаграмме коммуникаций – те же, что и для классов на диаграмме классов.
Проще всего привести описание диаграммы коммуникаций на примере:
На примере видим, что актор User взаимодействует с экземпляром страницы LoginPage, который в свою очередь работает с классом SecutiryManager, который оперирует объектами типа User.
Элементы диаграммы коммуникаций могут быть связаны отношением «Ассоциация». Как я уже указывал выше Ассоциация имеем достаточно широкое значение и может трактоваться по разному (см. Диаграммы классов).
Однако, в отличие от диаграмм последовательностей, где порядок инициации сообщений определяется шкалой времени, на диаграммах коммуникаций используется нумерация ассоциаций, которая определяет этот порядок.
Например:
3.5. Диаграммы состояний. (State diagram или State Machine)
Диаграммы состояний обычно применяются для иллюстрации того, как какой либо один элемент (обычно, один инстанцированный класс) переходит между различными своими состояниями. Диаграммы состояний также могут применяться как для описания состояний классов, так и бизнес-объектов.
Обычно диаграммы состояний имеют вспомогательную функцию и создаются в дополнение к другим поведенческим диаграммам.
Диаграммы состояний состоят из элементов двух основных типов: Состояний и Переходов.
Элемент Состояние (State) отображает состояние объекта или процесса в какой-либо момент времени.
Обозначается значком:
Название Состояния является его описанием, т.е., например, состояние
означает, что пользователь находится в «незалогиненном» состоянии.
Переход (Transition) – элемент, отображающий путь перехода из одного состояния в другое.
Например:
Для обозначения начала и конца всего процесса переходов используются псевдо-состояния: Инициирующее (Initial)
и Финализирующее (Final)
Применятся они могут, например, так:
Если Состояние сопряжено с некоторой деятельностью, то это тоже отображается на диаграмме.
Например:
Если из одного Состояния возможно несколько переходов в несколько других различных состояний, то это тоже отображается на диаграмме. Как правило, в этом случае переходы именуются по своему смыслу. Например, по результатам деятельности.
Например:
На примере видим, что после проверки логина и пароля пользователь может быть принят или отвергнут.
Другой вариант того же самого примера:
Этот пример отличается от предыдущего тем, что после ввода неверных данных пользователю больше не предлагается ввести свои данные.
Переход также может осуществляться между одним и тем же состоянием.
Например:
Кроме обычных Состояний (State) существуют также Суперсостяния (State Machine), которые могут включать в себя другие состояния и переходы.
При этом контекст Суперсостояния является актуальным для всех элементов, находящихся внутри этого Суперсостояния.
Например:
Суперсостояние само по себе может иметь переходы в другие состояния. В этом случае считается, что из любого Состояния внутри Суперсостояния может быть осуществлен такой переход.
Например:
На одной диаграмме состояний может быть отображено несколько одновременных состояний одного и того же объекта, если эти состояния изменяются параллельно друг другу.
Например (из книги Фаулера):
Если несколько параллельных потоков переходов должны быть синхронизироваться в какой-то момент, то для это используется псевдо-состояние Synch
Существует также дополнительный элемент Fork/Join – используется для разбивки или объединения нескольких потоков состояний.
Например:
3.6. Диаграммы деятельности. (Activity diagram)
Диаграммы деятельности относятся к диаграммам, описывающим поведение системы. Они во многом родственны диаграммам состояний и имеют множество сходных элементов, но выполняют несколько другую функцию. Диаграммы деятельности предназначены для описания потоков и последовательностей выполнения работ по реализации некоторого варианты использования. В отличие от диаграмм состояний, диаграммы деятельности принимают во внимание не состояние некоторого объекта, а потоки деятельности.
Обычно для диаграммы деятельности используются для описания сложных алгоритмов, бизнес-процессов, вариантов использования и пр. Диаграммы деятельности могут быть выражены как в терминах объектов системы, так и в терминах бизнес-объектов.
Основным объектом диаграмм активностей является Активность (Activity), которая обозначается следующим значком:
Диаграммы активностей имеют те же элементы, что и диаграммы состояний, а именно: псевдо-активности начала и конца потоков, переходы, Fork/Join, Суперактивности.
Пример:
На примере показан поток работ по работе с клиентом. Здесь видно, что диаграмма не посвящена состояниям только одного элемента или объекта – вместо этого она отражает поток деятельностей, который затрагивает различные элементы или подсистемы.
Кроме того, на этой диаграмме присутствует новый элемент Решение (Decision) –
Этот элемент знаком нам по блок-схемам и обозначает момент ветвления или соединения потоков. Отличие от Fork/Join состоит в том, что процесс продолжается только по одной ветке, в то время как после Fork/Join – по всем веткам параллельно.
Существенным дополнением диаграммы деятельности является элемент Partition, который сам по себе логического значения не имеет и предназначен для визуальной группировки работ по какому-либо признаку.
Обозначается значком:
Например:
На примере видно, что потоки работ условно сгруппированы в работу по обработке заказа и по проведению платежа.
Кроме обычных активностей, есть несколько дополнительных:
1. Отправка (Send) – используется для отображения запросов к каким-либо внешним источникам.
Обозначается:
2. Получение (Receive) – используется для получения информации от каких-либо внешних источников.
Обозначается:
Например:
4. Пакеты (Packages)
Пакеты – это способ группировки любых элементов языка UML – диаграмм, вариантов использования, классов и пр.
Обычно пакеты представляют собой:
· подсистемы, если речь идет о системе
· компоненты или слои, если речь идет о классах
· наборы бизнес-логики, если речь идет о вариантах использования и т.п.
Конкретный способ группировки элементов в пакеты остается на усмотрение проектировщика.
Пакет обозначается следующим образом:
Например, может существовать пакет Акторов —
в котором находятся диаграммы с перечнем Акторов.
Пакеты также могут соединяться различными видами ассоциаций для того, чтобы продемонстрировать их взаимозависимость.
Например:
Пакеты могут включать в себя не только объекты, но и диаграммы различных типов. Т.е. в каждом пакете могут быть свои диаграммы вариантов использования, последовательностей, классов и пр.
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Object Management Group (OMG) created UML and UML 1.0 specification draft was proposed to the OMG in January 1997. UML can be described as a general-purpose visual modeling language to visualize, specify, construct and document software systems. Although UML is generally used to model software systems it is not limited within this boundary. It is also used to model non-software systems as well like process flow in a manufacturing unit etc. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams.
- UML is a general-purpose modeling language. It was initially started to capture the behavior of complex software and non-software system and now it has become an OMG standard.
- UML provides elements and components to support the requirement of complex systems. UML follows the object-oriented concepts and methodology. So object-oriented systems are generally modeled using the pictorial language.
- UML diagrams are drawn from different perspectives like design, implementation, deployment, etc. At the conclusion, UML can be defined as a modeling language to capture the architectural, behavioral and structural aspects of a system.
- Objects are the key to this object-oriented world. The basic requirement of object-oriented analysis and design is to identify the object efficiently. After that, the responsibilities are assigned to the objects. Once this task is complete the design is done using the input from the analysis.
- The UML has an important role in this OO analysis and design; The UML diagrams are used to model the design. So the UML has an important role to play.
Purpose of UML
A picture is worth a thousand words, this absolutely fits while discussing UML. Object-oriented concepts were introduced much earlier than UML. So at that time, there were no standard methodologies to organize and consolidate the object-oriented development. At that point in time UML came into the picture. There are a number of goals for developing UML but the most important is:
- To define some general-purpose modeling language, which all modelers can use, and also it needs to be made simple to understand and use.
- Made for developers but also for business users, common people and anybody interested to understand the system.
- The system can be software or non-software.
- It must be clear that UML is not a development method rather it accompanies processes to make a successful system.
At the conclusion, the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.
Modeling Architecture Views using UML
Different users use any real-world system. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewers’ perspective. The better we understand the better we make the system. This set of views is known as the 4+1 Views of Software Architecture. UML plays an important role in defining different perspectives of a system. These perspectives are:
- Use Case View
+ 4 Architecture views
- Design
- Implementation
- Process
- Deployment
And the center is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with the use case.
- Use-case view: Describes the functionality of the system, its external interfaces, and its principal users. The use-case view contains the Use-Case Model. This view is mandatory when using the 4+1 Views because all elements of the architecture should be derived from requirements.
- Logical view: Describes how the system is structured in terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of Software Architecture.
- Implementation view: Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes the development of artifacts and deployment artifacts. This view is optional when using the 4+1 Views.
- Process view: Describes how the run-time system is structured as a set of elements that have run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It consists of rapidly changing networks of communication objects. The elements are components that have a run-time presence (processes, threads, Enterprise JavaBeans™ (EJB™), servlets, DLLs, and so on), data stores, and complex connectors, such as queues. Interaction between elements varies, based on technology. This view is useful for thinking about run-time system quality attributes, such as performance and reliability. This view is optional when using the 4+1 Views.
- Deployment views: Describe how the system is mapped to the hardware. This view is optional when using the 4+1 Views.
In addition, you may wish to represent the following:
- Data view: A specialization of the logical view. Use this view if persistence is a significant aspect of the system, and the translation from the design model to the data model is not done automatically by the persistence mechanism.
14 Type of Diagrams in UML 2
Diagrams are the heart of UML. These diagrams are broadly categorized as structural and behavioral diagrams.
- Structural diagrams are consists of static diagrams like class diagram, objects diagram, etc.
- Behavioral diagrams are consists of dynamic diagrams like sequence diagram, collaboration diagram, etc.
Structural Modeling
Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system and may include abstract, real-world and implementation concepts, there are seven types of structure diagram as follows:
- Classes diagrams
- Objects diagrams
- Deployment diagrams
- Package diagrams
- Composite structure diagram
- Component diagram
- Profile Diagram
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time, there are seven types of behavior diagrams as follows:
- Use Case Diagram
- Activity Diagram
- State Machine Diagram
- Sequence Diagram
- Communication Diagram
- Interaction Overview Diagram
- Timing Diagram
Class diagrams
Class diagrams are the most popular UML diagrams used by the object-oriented community. It describes the objects in a system and their relationships. A class diagram consists of attributes and functions.
A single class diagram describes a specific aspect of the system and the collection of class diagrams represents the whole system. Basically the class diagram represents the static view of a system.
Class diagrams are the only UML diagrams, which can be mapped directly with object-oriented languages. So it is widely used by the developer community.
Class Diagram Example
The following Class Diagram example represents two classes – User and Attachment. A user can upload multiple attachments so the two classes are connected with an association, with 0..* as multiplicity on the Attachment side.
Object Diagram
An object diagram is an instance of a class diagram. So the basic elements are similar to a class diagram. Object diagrams are consist of objects and links. It captures the instance of the system at a particular moment.
A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The difference is that a class diagram represents an abstract model consisting of classes and their relationships. However, an object diagram represents an instance at a particular moment, which is concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data structure.
Object Diagram Example
The following Object Diagram example shows you how the object instances of User and Attachment class “look like” at the moment Peter (i.e. the user) is trying to upload two attachments. So there are two Instance Specifications for the two attachment objects to be uploaded.
Component Diagram
Component diagrams are a special kind of UML diagram to describe the static implementation view of a system. Component diagrams consist of physical components like libraries, files, folders, etc.
This diagram is used from an implementation perspective. More than one component diagrams are used to represent the entire system. Forward and reverse engineering techniques are used to make executables from component diagrams.
Component Diagram Example
Deployment Diagram
Component diagrams are used to describe the static deployment view of a system. System engineers mainly use these diagrams.
Deployment diagrams are consist of nodes and their relationships. An efficient deployment diagram is an integral part of software application development.
Deployment Diagram Example
Package Diagram
The package diagram is a UML structure diagram that shows packages and dependencies between the packages. Model diagrams allow showing different views of a system, for example, as multi-layered (aka multi-tiered) application – multi-layered application model.
Package Diagram Example
Composite Structure Diagram
Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite structure diagram is similar to a class diagram and is a kind of component diagram mainly used in modeling a system at a micro point-of-view, but it depicts individual parts instead of whole classes. It is a type of static structure diagram that shows the internal structure of a class and the collaborations that this structure makes possible.
This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.
Composite Structure Diagram Example
Profile Diagram
A profile diagram enables you to create a domain and platform-specific stereotypes and define the relationships between them. You can create stereotypes by drawing stereotype shapes and relate them with composition or generalization through the resource-centric interface. You can also define and visualize the tagged values of stereotypes.
Profile Diagram Example
Use Case Diagram
A use-case model describes a system’s functional requirements in terms of use cases. It is a model of the system’s intended functionality (use cases) and its environment (actors). Use cases enable you to relate what you need from a system to how the system delivers on those needs. It consists of use cases, actors and their relationships. The use case diagram is used at a high-level design to capture the requirements of a system. It represents the system’s functionalities and its flow. Although the use case diagrams are not a good candidate for forward and reverse engineering but still they are used in a slightly different way to model it.
Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle by all team members.
Use Case Diagram Example
State Machine Diagram
A State Machine diagram (also known as statechart, state diagram or state transition diagram), developed by David Harel, is one of the seven diagrams used for modeling the dynamic nature of a system.
These diagrams are used to model the entire life cycle of an object. The activity diagram is a special kind of Statechart diagram.
The state of an object is defined as the condition where an object resides for a particular time and the object again moves to other states when some events occur. Statechart diagrams are also used for forward and reverse engineering.
State Machine Diagram Example
Activity Diagram
The activity diagram is another important diagram to describe dynamic behavior. The activity diagram consists of activities, links, relationships, etc. It models all types of flows like parallel, single, concurrent, etc. The activity diagram describes the flow control from one activity to another without any messages. These diagrams are used to model a high-level view of business requirements. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).
Activity Diagram Example
Sequence Diagram
The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case. With the advanced visual modeling capability, you can create a complex sequence diagram in a few clicks. Besides, some modeling tool such as Visual Paradigm can generate sequence diagram from the flow of events which you have defined in the use case description.
Sequence Diagram Example
Communication Diagram
Similar to the Sequence Diagram, the Communication Diagram is also used to model the dynamic behavior of the use case. When compared to the Sequence Diagram, the Communication Diagram is more focused on showing the collaboration of objects rather than the time sequence. They are actually semantically equivalent, so some of the modeling tools such as Visual Paradigm allows you to generate it from one to the other.
Communication Diagram Example
Interaction Overview Diagram
The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the “real” diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.
Interaction Overview Diagram Example
Timing Diagram
Timing Diagram shows the behavior of the object(s) in a given period of time. A timing diagram is a special form of a sequence diagram. The differences between the timing diagram and sequence diagram are the axes are reversed so that the time is an increase from left to right and the lifelines are shown in separate compartments arranged vertically.
Timing Diagram Example
Summary
- The UML is non- proprietary and open to all. It addresses the needs of the user and scientific communities, as established by experience with the underlying methods on which it is based.
- Many methodologists, organizations, and tool vendors have committed to using it. Since the UML builds upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has incorporated input from the UML partners and feedback from the general public, widespread adoption of the UML should be straightforward.
There are two aspects of “unified” that the UML achieves:
- First, it effectively ends many of the differences, often inconsequential, between the modeling languages of previous methods.
- Secondly, and perhaps more importantly, it unifies the perspectives among many different kinds of systems (business versus software), development phases (requirements analysis, design, and implementation), and internal concepts.