Унифицированный язык моделирования ( UML ) — это визуальный язык моделирования общего назначения , предназначенный для предоставления стандартного способа визуализации проекта системы. [1]
UML предоставляет стандартную нотацию для многих типов диаграмм, которые можно условно разделить на три основные группы: диаграммы поведения, диаграммы взаимодействия и диаграммы структуры.
Создание UML изначально было мотивировано желанием стандартизировать разрозненные системы обозначений и подходы к проектированию программного обеспечения. Он был разработан в Rational Software в 1994–1995 годах, а его дальнейшее развитие велось ими до 1996 года. [2]
В 1997 году UML был принят в качестве стандарта Object Management Group (OMG) и с тех пор управляется этой организацией. В 2005 году UML был также опубликован Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC) как стандарт ISO/IEC 19501. [3] С тех пор стандарт периодически пересматривался, чтобы соответствовать последней версии UML. [4]
В программной инженерии большинство специалистов не используют UML, а вместо этого создают неформальные диаграммы, нарисованные вручную; однако эти диаграммы часто включают элементы из UML. [5] : 536
UML развивался со второй половины 1990-х годов и имеет корни в методах объектно-ориентированного программирования, разработанных в конце 1980-х и начале 1990-х годов. Временная шкала (см. изображение) показывает основные моменты истории методов объектно-ориентированного моделирования и нотации.
Первоначально он основывался на нотациях метода Буча , технике объектного моделирования (OMT) и объектно-ориентированной программной инженерии (OOSE), которые он интегрировал в один язык. [6]
Корпорация Rational Software наняла Джеймса Рамбо из General Electric в 1994 году, и после этого компания стала источником двух самых популярных подходов объектно-ориентированного моделирования того времени: [7] Метод объектного моделирования Рамбо (OMT) и метод Грэди Буча . Вскоре им в их усилиях помог Ивар Якобсон , создатель метода объектно-ориентированной разработки программного обеспечения (OOSE), который присоединился к ним в Rational в 1995 году. [2]
Под техническим руководством этих трех (Рамбо, Якобсон и Буч) в 1996 году был организован консорциум под названием UML Partners для завершения спецификации Unified Modeling Language (UML) и предложения ее Object Management Group (OMG) для стандартизации. В партнерство также вошли дополнительные заинтересованные стороны (например, HP , DEC , IBM и Microsoft ). Проект UML 1.0 от UML Partners был предложен OMG в январе 1997 года консорциумом. В том же месяце UML Partners сформировали группу, призванную определить точное значение языковых конструкций, под председательством Криса Кобрина и под руководством Эда Эйкхольта, для завершения спецификации и ее интеграции с другими усилиями по стандартизации. Результатом этой работы стал UML 1.1, который был представлен OMG в августе 1997 года и принят OMG в ноябре 1997 года. [2] [8]
После первого выпуска была сформирована целевая группа [2] для улучшения языка, которая выпустила несколько небольших изменений: 1.3, 1.4 и 1.5. [9]
Разработанные им стандарты (как и первоначальный стандарт) были отмечены как неоднозначные и непоследовательные. [10]
Как и в случае с диаграммами баз данных Чена, Бахмана и ISO ER , модели классов специфицированы для использования "перекрестных" мощностей , хотя несколько авторов ( Мериз , [11] Элмасри и Навате, [12] среди прочих [13] ) предпочитают одностороннюю или "перекрестную" для ролей и как минимальных, так и максимальных мощностей. Недавние исследователи (Фейнерер [14] и Дуллеа и др. [15] ) показали, что техника "перекрестного" просмотра, используемая диаграммами UML и ER, менее эффективна и менее связна при применении к n -арным отношениям порядка строго больше 2.
Файнерер говорит: «Проблемы возникают, если мы работаем в рамках семантики «перекрестного просмотра», используемой для ассоциаций UML. Хартманн [16] исследует эту ситуацию и показывает, как и почему различные преобразования терпят неудачу». И: «Как мы увидим на следующих нескольких страницах, интерпретация «перекрестного просмотра» вносит несколько трудностей, которые мешают распространению простых механизмов с бинарных на n -арные ассоциации».
Основная редакция UML 2.0 заменила версию 1.5 в 2005 году, которая была разработана расширенным консорциумом для дальнейшего улучшения языка с учетом нового опыта использования его функций. [17]
Хотя UML 2.1 никогда не был выпущен как формальная спецификация, версии 2.1.1 и 2.1.2 появились в 2007 году, а затем UML 2.2 в феврале 2009 года. UML 2.3 был официально выпущен в мае 2010 года. [18] UML 2.4.1 был официально выпущен в августе 2011 года. [18] UML 2.5 был выпущен в октябре 2012 года как версия «В разработке» и был официально выпущен в июне 2015 года. [18] Формальная версия 2.5.1 была принята в декабре 2017 года. [1]
Спецификация UML 2.x состоит из четырех частей:
До UML 2.4.1 последними версиями этих стандартов были: [19]
Начиная с версии 2.5 спецификация UML была упрощена (без надстройки и инфраструктуры), и последние версии этих стандартов теперь следующие: [20]
Он продолжает обновляться и совершенствоваться рабочей группой по пересмотру, которая решает любые проблемы с языком. [21]
UML предлагает способ визуализации архитектурных чертежей системы в виде диаграммы, включая такие элементы, как: [6]
Хотя изначально UML предназначался для объектно-ориентированной проектной документации, он был расширен до более широкого набора проектной документации (как указано выше) [22] и оказался полезным во многих контекстах. [23]
UML сам по себе не является методом разработки; [24] однако он был разработан с учетом совместимости с ведущими объектно-ориентированными методами разработки программного обеспечения своего времени, например, OMT , методом Буча , Objectory и особенно RUP , для использования с которым он изначально предназначался, когда началась работа в Rational Software.
Важно различать модель UML и набор диаграмм системы. Диаграмма — это частичное графическое представление модели системы. Набор диаграмм не обязательно должен полностью покрывать модель, и удаление диаграммы не изменяет модель. Модель может также содержать документацию, которая управляет элементами модели и диаграммами (например, письменные варианты использования).
Диаграммы UML представляют собой два различных представления модели системы: [25]
Обмен моделями UML между инструментами UML возможен с помощью формата обмена метаданными XML (XMI).
В UML одним из ключевых инструментов для моделирования поведения является модель вариантов использования, вызванная OOSE . Варианты использования — это способ указания требуемых вариантов использования системы. Обычно они используются для фиксации требований системы, то есть того, что система должна делать. [26]
UML 2 имеет много типов диаграмм, которые делятся на две категории. [6] Некоторые типы представляют структурную информацию, а остальные представляют общие типы поведения , включая несколько, которые представляют различные аспекты взаимодействий . Эти диаграммы можно классифицировать иерархически, как показано на следующей диаграмме классов: [6]
Все эти диаграммы могут содержать комментарии или примечания, поясняющие использование, ограничения или намерения.
Структурные диаграммы представляют статические аспекты системы. Они подчеркивают то, что должно присутствовать в моделируемой системе. Поскольку структурные диаграммы представляют структуру, они широко используются при документировании архитектуры программного обеспечения программных систем. Например, компонентная диаграмма описывает, как программная система разделяется на компоненты, и показывает зависимости между этими компонентами.
Диаграммы поведения представляют динамический аспект системы. Они подчеркивают то, что должно произойти в моделируемой системе. Поскольку диаграммы поведения иллюстрируют поведение системы, они широко используются для описания функциональности программных систем. Например, диаграмма деятельности описывает пошаговые действия компонентов системы в бизнесе и эксплуатации.
Визуальное представление: Staff User → Complaints System: Submit Complaints System → HR System: Forward Complaints System → Department: Assign Complaints Department → Complaints System: Update Resolution Complaints System → Feedback System: Request Feedback Feedback System → Staff User: Provide Feedback Staff User → Feedback System: Submit Feedback Это описание можно использовать для рисования диаграммы последовательности с помощью таких инструментов, как Lucidchart, Draw.io или любого программного обеспечения для построения диаграмм UML. Диаграмма будет иметь актеров с левой стороны со стрелками, указывающими последовательность действий и взаимодействий между системами и актерами, как описано, пожалуйста Диаграмма последовательности drow Диаграммы последовательности должны быть нарисованы для каждого варианта использования, чтобы показать, как различные объекты взаимодействуют друг с другом для достижения функциональности варианта использования.
В UML артефакт [ 1] — это «спецификация физической части информации, которая используется или создается в процессе разработки программного обеспечения или при развертывании и эксплуатации системы». [1]
«Примерами артефактов являются файлы моделей, исходные файлы, скрипты и двоичные исполняемые файлы, таблица в системе базы данных , результат разработки, текстовый документ или почтовое сообщение». [1]
Артефакты — это физические сущности, которые развертываются на узлах [1] (т. е. устройствах и средах выполнения). Другие элементы UML, такие как классы и компоненты, сначала проявляются в артефактах, а затем развертываются экземпляры этих артефактов. Артефакты также могут состоять из других артефактов.
Группа управления объектами (OMG) разработала архитектуру метамоделирования для определения UML, называемую Meta-Object Facility . [27] MOF разработан как четырехслойная архитектура, как показано на изображении справа. Она предоставляет мета-метамодель наверху, называемую слоем M3. Эта M3-модель является языком, используемым Meta-Object Facility для построения метамоделей, называемых M2-моделями.
Наиболее ярким примером модели Layer 2 Meta-Object Facility является метамодель UML, которая описывает сам UML. Эти M2-модели описывают элементы M1-слоя и, таким образом, M1-модели. Это могут быть, например, модели, написанные на UML. Последний слой — это M0-слой или слой данных. Он используется для описания экземпляров системы во время выполнения. [28]
Метамодель может быть расширена с помощью механизма, называемого стереотипизацией . Это было раскритиковано как недостаточное/несостоятельное Брайаном Хендерсоном-Селлерсом и Сезаром Гонсалесом-Пересом в "Использование и злоупотребление механизмом стереотипов в UML 1.x и 2.0". [29]
В 2013 году компания OMG продвигала UML во многих контекстах, но в первую очередь она была нацелена на разработку программного обеспечения, но с ограниченным успехом. [23] [30]
Иногда его рассматривали как серебряную пулю дизайна , что приводило к проблемам. Неправильное использование UML включает в себя чрезмерное использование (проектирование каждой части системы с его помощью, что не является необходимым) и предположение, что новички могут проектировать с его помощью. [31]
Он считается большим языком со множеством конструкций . Некоторые люди (включая Якобсона ) считают, что размер UML затрудняет обучение и, следовательно, усвоение. [32]
MS Visual Studio прекратила поддержку UML в 2016 году из-за отсутствия использования. [33]
По данным Google Trends, с 2004 года UML неуклонно снижается. [34]
