Что такое унифицированный язык моделирования?

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

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

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

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

Объектно-ориентированные языки преобладают в сфере программирования, так как моделируют объекты реального мира. UML сочетает в себе несколько разновидностей объектно-ориентированной нотации — объектно-ориентированный дизайн, технику объектного моделирования и разработку объектно-ориентированного программного обеспечения.

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

«Три амиго» из мира программирования уже имели за плечами опыт создания других методологий, однако однажды решили общими усилиями разработать новые понятные стандарты для программистов. В итоге, сотрудничество Буча, Рамбо и Якобсона не только повысило эффективность всех трех методов, но и позволило отполировать их общий конечный продукт.

В 1996 году совместная работа трех светлых умов вылилась в релиз документов, составленных по принципам UML 0.9 и 0.91. Вскоре стало ясно, что некоторые крупные компании, включая Microsoft, Oracle и IBM, полагаются на UML как на один из ключевых инструментов развития своего бизнеса. Вместе с другими организациями и отдельными лицами эти компании обеспечили необходимые ресурсы для развития UML до уровня полностью сформировавшегося языка моделирования. В 1999 году «три амиго» опубликовали «Справочник пользователя унифицированного языка моделирования», а затем, в 2005 году, его вторую редакцию, где была представлена информация по UML 2.0.

Согласно сайту компании,Object Management Group® (OMG®) — международная некоммерческая организация с открытым членством, которая была основана в 1989 году и занимается стандартизацией технологий. Запрос на стандартизацию поступает от коммерческих организаций, конечных пользователей, учебных заведений и правительственных органов. Специалисты OMG разрабатывают стандарты интеграции корпоративной информации для широкого набора технологий и еще более широкого спектра отраслей. Стандарты моделирования OMG, включая UML и MDA® (Model Driven Architecture® — «архитектура, управляемая моделью»), позволяют своим пользователям эффективно проектировать, внедрять и поддерживать программные и другие процессы.

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

OMG определяет цель UML так:

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

UML выполняет следующие функции:

• задает формальное определение общей метамодели стандарта MOF (Meta-Object Facility — «метаобъектное средство»), где изложен абстактный синтаксис UML. Абстрактный синтаксис определяет набор концепций моделирования UML, а также их атрибуты, связи и правила объединения для построения моделей, частично или полностью основанных на UML;
• дает подробное объяснение семантике каждой концепции моделирования UML. Семантика определяет (без привязки к определенной технологии), как UML-концепции должны реализовываться компьютерами;
• задает понятные для человека элементы нотации для отображения отдельных концепций моделирования UML, а также правила объединения этих концепций в различные виды схем согласно тем или иным аспектам моделируемых систем;
• определяет требования, которым должны отвечать UML-инструменты в рамках данного стандарта. В дополнение прилагается отдельный стандарт на базе XML с указанием форматов обмена моделями (XMI), которые должны поддерживаться инструментами для работы с UML.

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

Язык UML не перестает совершенствоваться. Стандарт UML 2.0 расширяет границы UML, охватывая новые аспекты разработки, в том числе в гибкой среде. Новый стандарт был введен с целью реструктурировать, усовершенствовать и упростить UML для удобства использования, внедрения и адаптации. Вот несколько примеров того, как изменились диаграммы UML:

• более тесная интеграция между структурными и поведенческими моделями;
• возможность задавать иерархию и разбивать структуру программ на компоненты и подкомпоненты;
• повышение количества схем в UML 2.0 с 9 до 13.

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

• Правила абстрактного синтаксиса — пользователи могут перемещать модели из одной платформы в другую, даже если в них применяются разные системы нотации
• Общая метамодель хранилища данных (CWM) — набор стандартных интерфейсов, обеспечивающих возможность обмена метаданными хранилища и бизнес-аналитики между инструментами и платформами хранения, а также хранилищами метаданных в распределенных однородных средах
• Правила конкретного синтаксиса — возможность пользоваться знакомой системой нотации на разных платформах
• Ядро — в контексте UML, под ядром обычно подразумевается «ядерный пакет», который представляет собой полноценную метамодель, разработанную специально для эффективного многократного применения
• Языковая единица — коллекция тесно связанных концепций моделирования, которые дают пользователям возможность представить исследуемые аспекты системы согласно выбранной парадигме или формальной теории
• 0-й уровень (L0) — нижний уровень соответствия инфраструктуры правилам UML, то есть одна языковая единица, обеспечивающая возможность моделирования разнообразных классовых структур, которые встречаются в наиболее распространенных объектно-ориентированных языках программирования
• Метаобъектное средство (MOF) — набор правил моделирования OMG, на основе которого составляются определения метамодели в семействе MDA-языков OMG
• Метамодель — определяет язык и процессы, на основе которых составляется модель
• Конструктив метамодели (LM) — второй уровень соответствия инфраструктуры правилам UML, то есть дополнительная языковая единица, необходимая для более сложных классовых структур, применяемых для построения метамоделей с использованием полного объема метаобъектных средств (сокращенно CMOF), например, непосредственно языка UML. В UML выделяется только два уровня соответствия правилам языка.
• Архитектура, управляемая моделью (MDA) — подход, а также план по созданию целостного набора правил и технических характеристик, задаваемых моделью
• Объектный язык ограничений (OCL) — декларативный язык, описывающий правила, применимые к унифицированному языку моделирования. OCL дополняет UML терминами и символами блок-схем, которые характеризуются большей точностью, чем естественный язык, но при этом усваиваются проще, чем математические символы.
• Object Management Group (OMG) — некоммерческая организация, занимающаяся разработкой стандартов в сфере вычислительных технологий. Именно ее участники определяют и поддерживают стандарты UML.
• UML 1 — первая версия унифицированного языка моделирования
• Унифицированный язык моделирования (UML) — визуальный язык, позволяющий характеризовать, конструировать и документировать артефакты систем
• XMI — стандарт на основе XML, предназначенный для обмена моделями разных форматов

Просмотреть полный документ по метаобъектным средствам (MOF)

Скачать полный документ по инфраструктуре UML 2.4.1

В целом, в разработке систем выделяется три основных системных модели:

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

Наглядное представление этих системных моделей осуществляется с помощью схем двух разных типов — структурных и поведенческих.

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

Ниже приведены некоторые фундаментальные концепции объектно-ориентированной методологии:

• Объекты — сущности и простейшие строительные элементы схемы.
• Класс — прообраз объекта.
• Абстракция — поведение объекта реального мира.
• Инкапсуляция — механизм, позволяющий объединить данные и скрыть их от внешнего мира.
• Наследование — механизм создания новых классов на основе уже имеющихся.
• Полиморфизм — механизм, позволяющий объектам существовать в разных формах.

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

Структурные диаграммы UML

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

Поведенческие диаграммы UML

• Диаграммы активности схематично отображают потоки рабочих или операционных процессов, иллюстрируя активность в разных частях или компонентах системы. Диаграммы активности используются в качестве альтернативы диаграммам состояний.
• Схемы коммуникации напоминают диаграммы последовательностей, однако во главу угла ставят сообщения, передаваемые между объектами. Диаграммы последовательностей позволяют донести ту же информацию с помощью другого набора объектов.
• Диаграммы обзора взаимодействий. Существует семь разновидностей диаграмм взаимодействий, и на этой схеме показана последовательность их применения.
• Диаграммы последовательностей показывают, как и в какой последовательности объекты взаимодействуют между собой. Взаимодействие иллюстрирует определенный сценарий.
• State Diagram Similar to activity diagrams, they describe the behavior of objects that behave in varying ways in their current state.
• Временные диаграммы напоминают диаграммы последовательности, так как отображают поведение объектов в заданный отрезок времени. Простые диаграммы описывают один объект, тогда как сложные показывают взаимодействие нескольких объектов за указанный период.
• Схемы сценариев использования отображают конкретные функции системы и объясняют, как они соотносятся с внутренними/внешними контроллерами (агентами).

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

Уроки по созданию структурных схем

ДИАГРАММЫ КЛАССОВ

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

1. Классы отображаются с помощью прямоугольных блоков, разбитых на три части. В верхней части помещается наименование класса, в средней — его атрибуты, а в нижней — операции класса (которые также называют методами).
2. Чтобы смоделировать отношения между объектами, поместите на свою диаграмму фигуры для обозначения классов. Возможно, вам также пригодятся подклассы.
3. Используйте соединительные линии, чтобы показать связь, наследование, множественность и другие виды отношений между классами и подклассами. Выбор правильных линий будет зависеть от вашего предпочитаемого стиля нотации.

 

ДИАГРАММЫ КОМПОНЕНТОВ

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

1. Для изображения компонента на схеме используйте прямоугольный блок. Сбоку на нем должно располагаться два небольших прямоугольника (иногда они присутствуют прямо на значке фигуры).
2. Для обозначения связей используйте соединительные линии.

 

ДИАГРАММЫ РАЗВЕРТЫВАНИЯ

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

1. Диаграммы развертывания составляются с помощью той же нотации, что и диаграммы компонентов.
2. Чтобы смоделировать узел, используйте фигуру «трехмерный куб» (узел символизирует физический или виртуальный компьютер).
3. Сопроводите узел пометкой, как на диаграммах последовательностей. При необходимости добавьте другие узлы и соедините их линиями.

 

Уроки по созданию поведенческих схем

ДИАГРАММЫ АКТИВНОСТИ

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

1. Поместите в начало диаграммы круг с заливкой.
2. Соедините круг с первым действием, для обозначения которого применяется прямоугольник со скругленными углами.
3. Теперь соедините действия между собой при помощи линий, символизирующих пошаговую последовательность всего процесса.
4. Также попробуйте воспользоваться разделительными дорожками, чтобы разграничить объекты, задействованные в выполнении каждого действия.

 

СХЕМЫ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

 

ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТЕЙ

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

1. Чтобы создать диаграмму последовательностей, запишите название класса и его экземпляра внутри прямоугольного блока.
2. Проведите линии между экземплярами классов, чтобы обозначить отправителя и получателя сообщения.
3. Используйте стрелки с закрашенными наконечниками для обозначения синхронных сообщений, с открытыми — для асинхронных сообщений и пунктир — для ответов.

Начните создавать собственные диаграммы UML в Lucidchart уже сегодня! С нами строить схемы просто, эффективно и даже занимательно.

• Удобный интерфейс. Если вы взялись за создание диаграммы UML, вы, безусловно, знаете, что делать, однако мы решили дополнительно упростить вам работу. Отполированный интерфейс и интуитивный редактор Lucidchart сэкономят вам драгоценные минуты.
• Богатая библиотека фигур. С нами вы сможете составлять диаграммы состояний, активности и сценариев использования, как настоящий профессионал. В нашей обширной библиотеке фигур и соединительных линий вы найдете всё, что нужно для схем.
• Максимальная интеграция. Платформа Lucidchart полностью интегрирована с G Suite. Начав работу в Lucidchart, вы найдете наш сервис прямо в наборе Google для продуктивной работы по соседству с Gmail и Google Drive. Кроме того, для входа на Lucidchart можно использовать учетные данные Google.
• Возможность совместной работы. Созданной диаграммой UML можно с легкостью поделиться с коллегами, клиентами или начальством. Lucidchart позволяет встраивать диаграммы на веб-страницы, публиковать в формате PDF или использовать в качестве сопроводительных наглядных материалов с помощью режима презентации.
• Импорт/экспорт из Visio. Чтобы ваша работа в Visio не пропадала зря, предлагаем вам возможность свободно импортировать и экспортировать свои файлы. Это займет совсем немного времени и не составит труда.