UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
 UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью.
UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
 UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.
 Предпосылки появления языка моделирования UML обозначились в связи с бурным развитием во второй половине XX века объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++ и др). Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год количество объектно-ориентированных инструментов выросло с десятка до более чем полусотни. Однако многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди которого особую популярность приобрели метод Буча, созданный Якобсоном Object-Oriented Software Engineering (OOSE) и разработанный Рамбо Object Modeling Technique (OMT). Помимо них существовали и другие завершённые технологии, например Fusion, Shlaer-Mellor и Coad-Yourdon, однако всем из них были присущи не только преимущества, но и существенные недостатки.
 В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-Modeling Technique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.
 На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон («три амиго»), выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.
 На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.
 Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999, сентябре 2001 и марте 2003 года.
 UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.
 Формальная спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года.
 UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.
 В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
 Structure Diagrams:
 Behavior Diagrams:
 Структурные диаграммы:
 Диаграммы поведения:
 Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:
 Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
 Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
 Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
 Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
 Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.
 Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
 Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
 Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
 Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
 Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
 Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
 Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90 и дракон-схемы.
 Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.
 Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.
 Аналогом диаграмм автомата (диаграмм состояний) являются дракон-схемы.
 Диаграмма прецедентов или диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.
 Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
 Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.
 Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
 Диаграмма последовательности (Sequence diagram) —  диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
 Диаграмма сотрудничества — Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
 По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
 Диаграмма обзора взаимодействия — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
 Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
 Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
 Несмотря на то, что UML — достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков: