Руководство по UML-диаграммам

Лучше один раз увидеть, чем сто раз услышать. Именно поэтому был создан унифицированный язык моделирования (UML), ставший единым визуальным языком в сложном мире разработки ПО, понятным как бизнес-пользователям, так и всем, кто хочет разобраться в устройстве системы. Это руководство охватывает все, что нужно знать о UML. Даже если вы сталкивались с UML только во время официального обучения и с тех пор мало использовали его, он остается практичным способом сделать сложные системы понятными — особенно если применять его как «живую» документацию, а не как разовый рабочий продукт.

Что такое UML?

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

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

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

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

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

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

История и происхождение UML

Грейди Буч, Джеймс Рамбо и Ивар Якобсон, также известные как «три амиго» инженерии программного обеспечения, объединились, чтобы внести ясность в работу программистов путем создания новых стандартов.

Усилия этой группы привели к выпуску документов UML 0.9 и 0.91 в 1996 году. Вскоре стало очевидно, что ряд организаций, включая Microsoft, Oracle и IBM, рассматривают UML как критически важный элемент для развития собственного бизнеса. Они, наряду со многими другими лицами и компаниями, выделили ресурсы для разработки полноценного языка моделирования. В 1999 году «три амиго» опубликовали руководство пользователя The Unified Modeling Language User Guide, а в 2005 году вышло обновление, включающее UML 2.0.

Роль Object Management Group (OMG) в развитии UML

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

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

OMG определяет цель UML следующим образом:

• Предоставление системным архитекторам, инженерам программного обеспечения и разработчикам инструментов для анализа, проектирования и внедрения программных систем, а также для моделирования бизнес-процессов и аналогичных процессов.

• Развитие индустрии путем обеспечения совместимости инструментов визуального объектного моделирования. Однако для значимого обмена информацией о моделях между инструментами требуется соглашение о семантике и нотации.

UML отвечает следующим требованиям:

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

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

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

• Определение способов, с помощью которых инструменты UML могут быть приведены в соответствие с этой спецификацией. Это поддерживается (в отдельной спецификации) спецификацией соответствующих форматов обмена моделями на базе XML (XMI), которая должна быть реализована в совместимых инструментах.

Типы UML-диаграмм

UML использует элементы и связывает их различными способами для формирования статических диаграмм (представляющих структурные аспекты системы) и поведенческих диаграмм (представляющих динамические аспекты системы). Непосвященному человеку может показаться, что существует бесконечное количество UML-диаграмм, но на самом деле стандарты UML определяют 14 типов диаграмм, которые делятся на две группы, описанные ниже.

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

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

• Component diagram: диаграмма компонентов по сути является более специализированной версией диаграммы классов — для обеих применяются одни и те же правила нотации. Диаграмма компонентов разбивает сложную систему на более мелкие компоненты и визуализирует связи между ними.

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

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

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

• Package diagram: диаграммы пакетов используются для отображения зависимостей между различными пакетами в системе. Пакет, изображаемый в виде папки для файлов, организует элементы модели, такие как прецеденты или классы, в группы. Между пакетами определены два специальных типа зависимостей: импорт пакета (package import) и слияние пакета (package merge).

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

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

• Activity diagrams: диаграммы деятельности используются как альтернатива диаграммам состояний. Диаграммы деятельности визуализируют шаги, выполняемые в рамках прецедента — действия могут быть последовательными, разветвленными или параллельными. Этот тип UML-диаграмм используется для отображения динамического поведения системы, но также может быть полезен при моделировании бизнес-процессов.

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

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

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

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

• Timeline diagram: временную диаграмму, которую часто описывают как перевернутую диаграмму последовательности, показывает, как объекты взаимодействуют друг с другом в заданном временном диапазоне. Используйте эти диаграммы, чтобы увидеть, сколько времени занимает каждый шаг процесса, и найти области для улучшения.

• Use Case Diagram: диаграммы прецедентов (вариантов использования) моделируют взаимодействие пользователей, отображаемых в виде схематичных фигур («актеров»), с системой. Этот тип UML-диаграмм должен представлять собой высокоуровневый обзор отношений между актерами и системами, поэтому он служит отличным инструментом для объяснения работы системы нетехнической аудитории.

Глоссарий терминов UML

Ознакомьтесь со словарем UML, составленным на основе документа UML 2.4.1 и призванным помочь тем, кто не является членом OMG, понять часто используемые термины.

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

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

• Соответствие конкретному синтаксису: пользователи могут продолжать использовать знакомую им нотацию в различных инструментах.

• Ядро (Core): в контексте UML ядро обычно относится к «базовому пакету» (core package), представляющему собой полную метамодель, специально разработанную для высокой степени повторного использования.

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

• Уровень 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.

Концепции моделирования, определяемые UML

Разработка систем ориентирована на три различные системные модели:

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

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

Объектно-ориентированные концепции в UML

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

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

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

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

Почему команды до сих пор используют UML-диаграммы (особенно в Agile)

Если вы проходили какое-либо официальное обучение программированию, вам, скорее всего, рассказывали о UML-диаграммах во время учебы. Но как часто вы использовали их после этого? Поскольку создание UML-диаграмм требует определенного времени, а в среде Agile они довольно быстро устаревают, многие разработчики программного обеспечения забыли о них.

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

UML-диаграммы помогают инженерным командам:

• Быстро вводить в курс дела новых членов команды или разработчиков, переходящих из других команд.

• Ориентироваться в исходном коде.

• Планировать новые функции еще до начала написания кода.

• Проще общаться как с технической, так и с нетехнической аудиторией.

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

Как создать UML-диаграмму

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

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

1. Определите свою цель

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

2. Выберите правильный тип диаграммы

На основе требований к вашей системе выберите подходящую UML-диаграмму. Например, используйте диаграмму классов для объектно-ориентированной структуры системы, диаграмму последовательности — для взаимодействий, упорядоченных по времени, или диаграмму прецедентов — для иллюстрации функционала пользователей. (Совет: быстрее всего начать работу с одного из готовых UML-шаблонов Lucidchart.)

3. Включите библиотеки фигур UML

Поскольку UML использует строгий визуальный словарь, вам потребуются правильные символы. In Lucidchart нажмите «Дополнительные фигуры» в нижней части левого меню, введите в поиск «UML» и отметьте флажками нужные библиотеки фигур (например, UML-классы, UML-состояния, UML-последовательности).

4. Добавьте и настройте фигуры

Перетащите сущности, объекты, узлы или актеров на холст. Расположите их логично и дважды щелкните внутри фигур, чтобы добавить пользовательский текст, определенные атрибуты и операции для ваших объектов.

5. Соедините компоненты

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

6. Проверьте и организуйте совместную работу

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

Станьте евангелистом UML

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

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

Кроме того, с Lucidchart создание UML-диаграмм превращается из рутины в ценный актив.