Виды диаграмм UML. Программные средства, поддерживающие язык uml

UML предназначен для моделирования. Сами авторы UML определяют свое детище следующим образом.

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

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

1.2.1. Спецификация

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

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

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

Спецификация ‒ это декларативное описание того, как нечто устроено или работает.

Необходимо принимать во внимание три толкования спецификаций.

• То, которое имеет в виду действующее лицо, являющееся источником спецификации (например, заказчик).
• То, которое имеет в виду действующее лицо, являющееся потребителем спецификации (например, разработчик).
• То, которое объективно обусловлено природой специфицируемого объекта.

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

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

1.2.2. Визуализация

Известная поговорка гласит, что лучше один раз увидеть, чем сто раз услышать. Мы добавим: тем паче тысячу раз прочитать пересказ. Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем голый текст. А картинки с текстом (это называется "комиксы") ‒ еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются. Фактически, развитие и детализация этого тезиса составляет большую часть содержания остальной части книги. Мы не будем забегать вперед, и просто приведем пример без всяких объяснений.

Разве что-нибудь непонятно?

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

Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.

1.2.3. Проектирование

В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином "проектирование". Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код. Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения.

По-английски автоматическое построение модели по коду готового приложения называется reverse engineering и обычно переводится на русский как "обратное проектирование". Нам этот перевод категорически не нравится: какое же это проектирование и почему оно обратное? Есть неплохой альтернативный вариант: "инженерный анализ программ", но он не получил пока распространения.

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

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

1.2.4. Документирование

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

XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.

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

1.2.5. Чем НЕ является UML

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

∇ Информационным технологиям от силы полвека ‒ это еще младенческий возраст для новой области человеческой деятельности.

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

Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Magic Draw , Rational Rose Enterprise , Visual Paradigm , Enterprise Architect , и др.). Сам язык никоим образом не навязывает то, как его нужно поддерживать инструментальными средствами. Решение всех вопросов, связанных с реализацией UML на компьютере полностью отдано на откуп разработчикам инструментов.

В-третьих, UML не является моделью процесса разработки приложений (хотя модель процесса разработки необходима и имеется множество различных моделей, предложенных разными авторами). Конечно, у авторов UML есть собственная модель процесса ‒ Rational Unified Process (RUP), которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без оной.

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

1.2.6. Способы использования UML

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

Рисование картинок . Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.

Обмен информацией . Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других "с полувзгляда".

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

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

Вариант использования drawing ("Рисование диаграмм") подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.

Вариант использования modeling ("Моделирование систем") подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем для краткости называть такой артефакт просто моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором Architect .

Вариант использования development ("Разработка приложений") подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.

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

Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.

В 90-х годах наиболее популярными были три объектно-ориентированных подхода:

В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии - дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.

Рис. 1. UML и его предшественники

Данная унификация преследовала три основные цели:

Моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;

Разрешение проблем масштабирования в сложных системах;

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

Официальной датой начала работ по UML считают октябрь 1994 года, когда Рамбо перешел в компанию Rational (ныне Rational - одно из подразделений корпорации IBM). Последним стандартом этого языка является версия UML1.3, вышедшая в 1999 году.

Средства UML-моделирования

Является ли UML необходимым компонентом RUP? Да, безусловно. Но практика использования UML как средства описания процесса моделирования и разработки программного обеспечения не ограничивается RUP. Как и любой другой язык, UML - это всего только средство. В RUP предусмотрен ряд утилит, позволяющих довольно легко использовать UML, но их набор не ограничивается лишь продуктами IBM/Rational. Ниже приводится далеко не полный список некоторых продуктов, поддерживающих UML:

Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i);

Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, платформы: Windows 98/NT/2000/XP/Server 2003);

Describe Enterprise (Embarcadero technologies, платформы: Windows 98/NT/2000/XP);

Семейство продуктов Together (Borland, платформы: Windows 98/NT/2000/XP, Linux, Solaris);

Bold for Delphi (Borland, платформы: Windows 98/NT/2000/XP);

MagicDraw (Magic, Inc., платформы: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);

QuickUML (ExcelSoftware, платформы: Windows 98/NT/2000/XP) - неплохая утилита для начинающих.

Отметим также некоторые продукты OpenSourse, например ArgoUML, Novosoft UML Library.

Документ, который содержит списки продуктов, поддерживающих UML, компаний-производителей, платформ, а также информацию о примерных ценах продуктов, можно найти по адресу: http://www.objectsbydesign.com/tools/umltools_byCompany.html .

Следует также отметить, что, несмотря на факт существования стандарта UML 1.3, поддерживаемые перечисленными продуктами реализации UML или обладают собственными особенностями, или не полностью следуют стандарту, поэтому при выборе средства моделирования следует обращать внимание на поддерживаемые типы диаграмм и особенности синтаксиса. Кроме того, возможности прямого и обратного проектирования (Round-Trip Engineering) в разных продуктах весьма различны. Не все вышеуказанные продукты могут поддерживать языки программирования Java, C++, CORBA IDL, поэтому следует обращать особое внимание на то, какую модель сможет сгенерировать тот или иной продукт из имеющегося у вас кода, на каком языке может быть получен код из вашей UML-модели и какого она должна быть типа.

Таблица, показывающая, какие диаграммы UML реализованы в том или ином продукте, находится по адресу: http://www.jeckle.de/umltools.htm .

Для чего применяется UML

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

UML — это язык визуализации. Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).

UML — это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.

UML — это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.

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

Элементы языка

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

Сущности

Структурные сущности являются существительными языка (рис. 2). К ним относятся:

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

интерфейсы (Interface) — это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс;

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

Прецеденты (Use case) — описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

активные классы (Active class) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

компоненты (Component) — это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент — это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание;

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

Данные перечисленных семи типов объектов являются базовыми структурными объектами UML. Существуют также вариации данных объектов, такие как действующие лица (Actor), сигналы (Signal), утилиты (Utility - вид класса), процессы и нити (Process и Thread - виды активного класса), приложения (Application), документы (document), файлы (File), библиотеки (Library), страницы (Page), таблицы (Table).

Поведенческие сущности — это динамические части моделей UML (рис. 3). К ним относятся:

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

автоматы (State machine) — спецификации поведения, представляющие собой последовательности состояний, через которые проходит в течение своей жизни объект, или взаимодействие в ответ на происходящие события (а также ответные действия объекта на эти события). Автомат прикреплен к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров. Изображается автомат как прямоугольник с закругленными углами.

Группирующие сущности — это организационные составляющие моделей UML. К ним относятся пакеты (Package) — обобщенный механизм для организации элементов в группы. Структурные, поведенческие, группирующие сущности могут быть помещены в пакет. Пакеты являются чисто концептуальными сущностями — в отличие от компонентов, существующих во время исполнения программы. Изображается пакет как папка с ярлыком сверху и, как правило, имеет только имя.

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

Отношения

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие (рис. 5):

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

- абстракция (Abstraction) — представляет собой изменение уровня абстрактности для некоторого понятия. Как правило, один из элементов, более абстрактный, а второй — более конкретный, хотя возможны ситуации, когда оба элемента являются двумя возможными вариантами понятия, существующими на одном уровне абстракции. К зависимости абстракции относятся следующие стереотипы (в порядке возрастания специфичности отношений): трассировать (Trace), уточнять (Refine), реализовать (есть собственная нотация) и выводить (Derive),

- связывание (Binding) — связывает элемент с шаблоном. Аргументы, необходимые для параметров шаблона, прикреплены к зависимости связывания в виде списка,

- комбинирование (Combination) — соотносит две части описания классификатора (любой элемент модели, описывающий определенные черты структуры и поведения системы), чтобы получить полное описание элемента,

- разрешение (Permission) — зависимость (всегда изображается в виде особого стереотипа), связывающая тот или иной пакет (или класс) с другим пакетом (или классом), которому он предоставляет разрешение использовать свое содержимое. Стереотипами зависимости разрешения являются: быть доступным (Access), быть дружественным (Friend) и импортировать (Import),

- использование (Usage) — описывает ситуацию, когда одному элементу для правильной реализации или функционирования требуется присутствие другого элемента. К стереотипам этого вида зависимости относятся: вызывать (Call), создать экземпляр (Instantiate), параметр (Parameter) и отправить (Send);

ассоциация (Association) — структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) — это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например сколько раз один объект может появляться в связях (множественность). Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

обобщение (Generalization) — это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка — Child) можно подставить вместо объектов обобщенного элемента (родителя, предка — Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок — подклассом;

реализация (Realization) — отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Мы перечислили четыре основных отношения. В UML также существуют их варианты: уточнение (Refinement), трассировка (Trace), включение (Include), расширение (Extend).

Диаграммы UML

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

Чаще всего UML рассматривает систему с пяти взаимосвязанных точек зрения (рис. 6).

Представление с точки зрения прецедентов (Use case view) включает пользовательские истории, описывающие систему с точки зрения конечного пользователя, аналитика, тестера. Это представление не определяет структуру программного обеспечения, а существует для передачи общего представления о системе. В UML это отображается посредством диаграмм прецедентов (Use case diagram), динамический аспект представлен в диаграммах взаимодействий (Interaction diagram), состояний (Statechart diagram), активности (Activity diagram).

Представление с точки зрения дизайна (Design view) включает классы, интерфейсы и кооперации, которые формируют словарь задачи и ее решение. Данное представление в первую очередь осуществляет поддержку функциональных требований к системе, значение сервисов, которые система должна предоставить конечному пользователю. В UML это отображается посредством диаграмм классов (Class diagram) и объектов (Object diagram), динамический аспект отображается в диаграммах взаимодействий, состояний, активности.

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

Представление с точки зрения реализации (Implementation view) включает компоненты и файлы, используемые при сборке системы. Подобное представление в первую очередь относится к управлению конфигурациями (Configuration management) релизов продукта. Статический аспект в UML отображен диаграммой компонентов (Component diagram), а динамический - диаграммами взаимодействий, состояний, активности.

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

Ниже приведены определения и примеры диаграмм:

диаграмма классов (Class diagram) — структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними (рис. 7);

диаграмма объектов (Object diagram) — структурная диаграмма, на которой показано множество объектов и отношений между ними. Ее можно считать особым случаем диаграммы классов. Инструментам моделирования не нужно поддерживать отдельный формат для диаграмм объектов. На них изображены объекты, поэтому диаграмма классов, на которой нет классов, но есть принадлежащие им объекты, может считаться диаграммой объектов;

диаграмма прецедентов (Use case diagram) — диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношений между ними (рис. 8);

диаграммы взаимодействий (Interaction diagram) :

- диаграмма последовательностей (Sequence diagram) — диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий (рис. 9),

- диаграмма кооперации (Collaboration diagram) — диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения (рис. 10);

диаграмма состояний (Statechart diagram) — диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий (рис. 11);

диаграмма активности (Activity diagram) — диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой (рис. 12);

диаграмма компонентов (Component diagram) — диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними, — относится к статистическому виду системы (рис. 13);

диаграмма топологии системы (Deployment diagram) — структурная диаграмма, на которой показаны узлы и отношения между ними (рис. 14).

Продолжение следует.

Структурные диаграммы: Диаграмма классов Диаграмма компонентов Композитной составной структуры Диаграмма кооперации UML2.0 Диаграмма развёртывания Диаграмма объектов Диаграмма пакетов Диаграмма профилей UML2.2 Диаграммы поведения: Диаграмма деятельности Диаграмма состояний Диаграмма прецедентов Диаграммы взаимодействия: Диаграмма коммуникации UML2.0 Диаграмма кооперации UML1.

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

Методология UML. UML-диаграммы.

Методология UML

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

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

Использование

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

Диаграммы

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Структуру диаграмм 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 и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

PAGE 7

Достоинства UML

• 1. UML объектно-ориентированный язык, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
• 2. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• 3. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
• 4. Сокращение числа возможных ошибок таких как: несогласованные параметры подпрограмм, несогласованное изменение атрибутов;
• 5. Повторное использование. Предполагается какой-либо вариант многократного использования уже существующего проекта или его части в новом проекте;
• 6. UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
• 7. UML получил широкое распространение и динамично развивается.

Недостатки UML

Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

• 1. Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше компромиссов.
• 2. Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений -- формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
• 3. Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
• 4. Только код отражает код. Ещё одно мнение -- что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
• 5. Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки -- термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
• 6. Пытается быть всем для всех. UML -- это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
• 7. Усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области, и для которых невозможно найти человека, понимающего эту предметную область в целом также требует использования традиционных подходов, в виду их большей доступности для неспециалистов.

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

Зачем она нужна?

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

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

Также стоит отметить, что есть несколько видов таких диаграмм.

Диаграмма классов

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

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

Диаграмма компонентов

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

Диаграмма композитной/составной структуры

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

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

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

Диаграмма развертывания

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

Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.

Диаграмма объектов

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

Диаграмма пакетов

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

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

Диаграмма деятельности

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

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

Диаграмма автомата

Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.

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

В качестве аналогов таких диаграмм могут использоваться так называемые дракон-схемы.

Диаграммы сценариев использования

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

Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:

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

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

Коммуникации

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

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

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

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

Диаграмма последовательности

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

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

Диаграмма сотрудничества

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

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

Диаграммы обзора взаимодействия

Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.

Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.

Диаграмма синхронизации

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

В чем преимущества?

Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

• Избыточность. В преимущественном большинстве случаев критики говорят о том, что UML является слишком большим и сложным, и зачастую это неоправданно. В него входит достаточно много избыточных или же практически бесполезных конструкций и диаграмм, причем наиболее часто подобная критика идет в адрес второй версии, а не первой, потому что в более новых ревизиях присутствует большее количество компромиссов «разработанных комитетом».
• Различные неточности в семантике. По той причине, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, которая является присущей для языков, точно определенных техникой формального описания. В определенных ситуациях абстрактный синтаксис OCL, UML и английский начинают друг другу противоречить, в то время как в других случаях они являются неполными. Неточность описания самого языка одинаково отражается как на пользователях, так и на поставщиках инструментов, что в конечном итоге приводит к несовместимости инструментов из-за уникального способа трактовки различных спецификаций.
• Проблемы в процессе внедрения и изучения. Все указанные выше проблемы создают определенные сложности в процессе внедрения и изучения UML, и в особенности это касается тех случаев, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
• Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а непосредственно рабочие системы, то есть код и есть проект. В соответствии с данным мнением есть потребность в том, чтобы разработать более эффективный способ написания программного обеспечения. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на самом деле этого может быть недостаточно, потому что в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в конечном итоге будет ограничиваться тем, что может предположить или же определить интерпретирующий UML инструмент.
• Рассогласование нагрузки. Данный термин происходит из теории системного анализа для определения неспособности входа определенной системы воспринять выход иной. Как в любых стандартных системах обозначений, UML может представлять одни системы в более эффективном и кратком виде по сравнению с другими. Таким образом, разработчик больше склоняется к тем решениям, которые являются более комфортными для переплетения всех сильных сторон UML, а также других языков программирования. Данная проблема является более очевидной в том случае, если язык разработки не соответствует основным принципам объектно-ориентированной ортодоксальной доктрины, то есть не старается работать в соответствии с принципами ООП.
• Пытается быть универсальным. UML представляет собой язык моделирования общего назначения, который старается обеспечить совместимость с любым существующим на сегодняшний день языком обработки. В контексте определенного проекта, для того, чтобы команда проектировщиков смогла добиться конечной цели, нужно выбирать применимые возможности этого языка. Помимо этого возможные пути ограничения сферы использования UML в какой-то определенной области проходят через формализм, который является не полностью сформулированным, а который сам представляет собой объект критики.

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