UML-диаграмма

 [скрыть]. 

• 1 История
• 1.1 До UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Дизайн
• 2.1 Методы разработки программного обеспечения
• 2.2 Моделирование
• 3 Диаграммы
• 3.1 Структурные диаграммы
• 3.2 Диаграммы поведения
• 3.2.1 Диаграммы взаимодействия
• 4 Мета-моделирование
• 5 Принятие
• 6 Критика
• 6.1 Критика UML 1.x

История объектно-ориентированных методов и нотации

UML развивается со второй половины 1990-х годов и уходит своими корнями в объектно-ориентированные методы, разработанные в конце 1980-х и начале 1990-х годов. На временной шкале (см. рисунок) показаны основные моменты истории методов объектно-ориентированного моделирования и нотации.

Изначально он основан на нотациях метода Буха, техники объектного моделирования (OMT) и объектно-ориентированной программной инженерии (OOSE), которые он объединил в единый язык. ^[5]

До UML 1.x[править источник | править]

Rational Software Corporation наняла Джеймса Румбо из General Electric в 1994 году, после чего компания стала источником двух самых популярных на сегодняшний день подходов объектно-ориентированного моделирования:^[6] Техника объектного моделирования Румбо (OMT) и метод Грейди Буча. Вскоре им помог Ивар Якобсон, создатель метода объектно-ориентированной программной инженерии (OOSE), который присоединился к ним в Rational в 1995 году. ^[1]

Под техническим руководством этих троих (Румбо, Джейкобсон и Бух) в 1996 году был организован консорциум под названием UML Partnerswas для завершения разработки спецификации унифицированного языка моделирования (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 года. ^[1][7]

UML 1.x[edit source | edit]

После первого выпуска была сформирована^[1] рабочая группа по улучшению языка, которая выпустила несколько небольших редакций, 1.3, 1.4 и 1.5. ^[8]

Созданные им стандарты (как и первоначальный стандарт) были отмечены как неоднозначные и непоследовательные. ^[9][10]

UML 2.x[edit source | edit]

Основная редакция UML 2.0 заменила версию 1.5 в 2005 году, которая была разработана при участии расширенного консорциума для дальнейшего совершенствования языка с учетом нового опыта использования его^[11] возможностей.

Хотя UML 2.1 так и не был выпущен в качестве официальной спецификации, версии 2.1.1 и 2.1.2 появились в 2007 году, а затем UML 2.2 в феврале 2009 года. UML 2.3 был официально выпущен в мае 2010 года.^[12] UML 2.4.1 был официально выпущен в августе 2011 года.^[12] UML 2.5 был выпущен в октябре 2012 года как версия "В процессе" и официально вышел в июне 2015 года. ^[12]

В спецификации UML 2.x есть четыре части:

1. Надстройка, определяющая нотацию и семантику для диаграмм и их элементов модели
2. Инфраструктура, определяющая основную метамодель, на которой базируется Надстройка
3. Язык объектных ограничений (Object Constraint Language, OCL) для определения правил для элементов модели
4. UML Diagram Interchange, который определяет, как происходит обмен макетами диаграмм UML 2

Текущие версии этих стандартов следующие: UML Superstructure версии 2.4.1, UML Infrastructure версии 2.4.1, OCL версии 2.3.1 и UML Diagram Interchange версии 1.0.^[13] Язык продолжает обновляться и совершенствоваться рабочей группой по пересмотру, которая решает любые проблемы с языком. ^[14]

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

• Любая деятельность (работа)
• Отдельные компоненты системы
• И как они могут взаимодействовать с другими компонентами программного обеспечения.
• Как будет работать система
• Как сущности взаимодействуют с другими (компоненты и интерфейсы)
• Внешний пользовательский интерфейс

Хотя первоначально унифицированный язык моделирования (UML) предназначался исключительно для объектно-ориентированной проектной документации, он был расширен, чтобы охватить более широкий набор проектной документации (как перечислено выше), ^[15]и оказался полезным во многих контекстах. ^[16]

Методы разработки программного обеспечения[править источник | edit]

UML сам по себе не является методом разработки; ^[17]однако он был разработан так, чтобы быть совместимым с ведущими объектно-ориентированными методами разработки программного обеспечения своего времени (например, сOMT, Booch method, Objectory) и особенно с RUP, который изначально предполагалось использовать, когда работа над ним началась в Rational Software Inc.

Моделирование[править источник | править]

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

Диаграммы UML представляют два различных взгляда на модель^[18] системы:

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

Обмен моделями UML между инструментами UML может осуществляться с помощью формата обмена метаданными XML Metadata Interchange (XMI).

В UML 2 имеется множество типов диаграмм, которые делятся на две категории.^[5] Некоторые типы представляют структурную информацию, а остальные - общие типы поведения, включая несколько, которые представляют различные аспекты взаимодействия. Эти диаграммы можно разделить на иерархические категории, как показано на следующей диаграмме^[5] классов:

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

Структурные диаграммы[править источник | edit]

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

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

Поведенческие диаграммы[править источник | править]

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

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

Диаграммы взаимодействия[править источник | править]

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

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

Основная статья: Мета-объектная среда

Иллюстрация механизма мета-объектов

Object Management Group (OMG) разработала архитектуру метамоделирования для определения унифицированного языка моделирования (UML), которая называется Meta-Object Facility (MOF).^[19] Meta-Object Facility разработана как четырехслойная архитектура, как показано на рисунке справа. Она предоставляет мета-модель на верхнем уровне, называемом уровнем M3. Эта M3-модель является языком, используемым Meta-Object Facility для построения метамоделей, называемых M2-моделями.

Наиболее ярким примером модели метаобъектного объекта второго уровня является метамодель UML, модель, описывающая сам UML. Эти M2-модели описывают элементы M1-уровня, а значит, и M1-модели. Это могут быть, например, модели, написанные на языке UML. Последний слой - это M0-слой или слой данных. Он используется для описания экземпляров системы во время выполнения. ^[20]

Мета-модель может быть расширена с помощью механизма, который называется стереотипизацией. Брайан Хендерсон-Селлерс и Сезар Гонсалес-Перес в работе "Использование и злоупотребление механизмом стереотипов в UML 1.x и 2.0" критикуют его как недостаточный/недостаточный. ^[21]

UML был признан полезным во многих контекстах проектирования,^[16] настолько, что стал практически вездесущим в ИТ^[22]-сообществе.

Иногда к нему относятся как к серебряной пуле в проектировании, что приводит к проблемам в его использовании. Неправильное использование включает в себя чрезмерное его использование (проектирование каждой маленькой части кода системы с его помощью, что является излишним) и предположение, что любой может спроектировать что угодно с его помощью (даже те, кто не программировал). ^[23]

Считается, что это большой язык, в котором много конструкций. Некоторые (включая Якобсона) считают, что их слишком много и что это мешает его изучению (и, следовательно, использованию). ^[24]

Распространенная критика UML со стороны промышленности включает: ^[4]

• не полезен: "[не] предлагает им преимуществ по сравнению с их нынешними, развитыми практиками и представлениями".
• слишком сложный, особенно для общения с клиентами: "неоправданно сложный" и "Лучшая причина не использовать UML - это то, что он не "читабелен" для всех заинтересованных сторон. Сколько стоит UML, если бизнес-пользователь (клиент) не может понять результат ваших усилий по моделированию?".
• необходимость синхронизации UML и кода, как и документации в целом

Критика UML 1.x[edit source | edit]

Условные обозначения кардинальности

Как и в диаграммах баз данных Chen, Bachman и ISO ER, модели классов определены для использования кардинальности "look-across", хотя некоторые авторы (Merise, ^[25]Elmasri & Navathe^[26] и др^[27].) предпочитают "look-ide" или "look-here" для ролей и как минимальную, так и максимальную кардинальность. Недавние исследователи (Feinerer, ^[28]Dullea и др.^[29]) показали, что техника "look-across", используемая в диаграммах UML и ER, менее эффективна и менее последовательна, когда применяется к n-арным отношениям порядка >2.

Файнерер говорит: "Проблемы возникают, если мы оперируем семантикой look-across, используемой для ассоциаций UML. Хартманн^[30] исследует эту ситуацию и показывает, как и почему различные преобразования не работают". (Хотя упомянутое "сокращение" является надуманным, поскольку две диаграммы 3.4 и 3.5 на самом деле одинаковы), а также "Как мы увидим на следующих нескольких страницах, интерпретация look-across создает несколько трудностей, которые препятствуют распространению простых механизмов с бинарных на n-арные ассоциации".