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
, однако всем из них были присущи не только преимущества, но и существенные недостатки
[1]
.
В
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 года
.
Версия
|
Дата принятия
|
1.1
|
ноябрь 1997
[2]
|
1.3
|
март 2000
[3]
|
1.4
|
сентябрь 2001
[4]
|
1.4.2
|
июль 2004
[3]
|
1.5
|
март 2003
[5]
|
2.0
|
июль 2005
[6]
|
2.1
|
формально не была принята
[3]
|
2.1.1
|
август 2007
[7]
|
2.1.2
|
ноябрь 2007
[8]
|
2.2
|
февраль 2009
[9]
|
2.3
|
май 2010
[10]
|
2.4 beta 2
|
март 2011
[11]
|
2.5
|
июнь 2015
[12]
|
2.5.1
|
декабрь 2017
[13]
|
На волне растущего интереса к 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
[12]
.
Формальная спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development ?
MDD
. Последняя версия UML 2.5 опубликована в июне 2015 года.
UML 2.4.1 принят в качестве международного стандарта
ISO
/
IEC
19505-1, 19505-2
[12]
.
В 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 объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам
программирования
на современных
объектно-ориентированных языках
;
- UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
- Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
- UML расширяет и позволяет вводить собственные текстовые и графические
стереотипы
, что способствует его применению не только в сфере программной инженерии;
- UML получил широкое распространение и динамично развивается.
Несмотря на то, что UML ? достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:
- Избыточность
языка
. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше ≪разработанных комитетом≫ компромиссов.
- Неточная
семантика
. Так как UML определён комбинацией себя (абстрактный синтаксис),
OCL
(языком описания ограничений ? формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками
формального описания
. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
- Проблемы при изучении и внедрении
. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков
[14]
.
- Только код отражает код
. Ещё одно мнение ? что важны рабочие системы, а не красивые модели. Как лаконично выразился
Джек Ривс
, ≪The code is the design≫ (≪Код и есть проект≫)
[15]
[16]
. В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые
компилируют модели
для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств
полноты по Тьюрингу
и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
- Кумулятивная нагрузка/Рассогласование нагрузки
(Cumulative Impedance/Impedance mismatch).
Рассогласование нагрузки
? термин из теории
системного анализа
для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
- Пытается быть всем для всех
. UML ? это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
- Крэг Ларман.
Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. ? 3-е изд. ?
М.
:
Вильямс
, 2006. ? 736 с. ?
ISBN 0-13-148906-2
.
- Джозеф Шмуллер.
Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. ?
М.
:
Вильямс
, 2005. ? 416 с. ?
ISBN 0-672-32640-X
.
- Грейди Буч, Джеймс Рамбо, Айвар Джекобсон.
Язык UML. Руководство пользователя = The Unified Modeling Language user guide. ? 2-е изд. ?
М.
,
СПб.
:
ДМК Пресс
,
Питер
, 2004. ? 432 с. ?
ISBN 5-94074-260-2
.
- Буч Г., Якобсон А., Рамбо Дж.
UML. Классика CS / С. Орлов. ? 2-е изд.. ?
СПб.
: Питер, 2006. ? 736 с. ?
ISBN 5-46900-599-2
.
- Леоненков А. В. Самоучитель UML 2. ? СПб.: БХВ-Петербург, 2007. ? 576 с.: ил.
ISBN 978-5-94157-878-8
![Перейти к шаблону «UML»](//upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Wikipedia_interwiki_section_gear_icon.svg/14px-Wikipedia_interwiki_section_gear_icon.svg.png) |
---|
|
Концепции
|
---|
Структура
| |
---|
Поведение
| |
---|
Отношения
| |
---|
Растяжимость
| |
---|
|
|
|
---|
Структурные
| |
---|
Поведения
| |
---|
Взаимодействия
| |
---|
|
|
![Перейти к шаблону «Software Engineering»](//upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Wikipedia_interwiki_section_gear_icon.svg/14px-Wikipedia_interwiki_section_gear_icon.svg.png) |
---|
Процесс
| |
---|
Высокоуровневые
концепции
| |
---|
Направления
| |
---|
Методологии
разработки
| |
---|
Модели
| |
---|
Известные
деятели
| |
---|
![Перейти к шаблону «Стандарты ISO»](//upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Wikipedia_interwiki_section_gear_icon.svg/14px-Wikipedia_interwiki_section_gear_icon.svg.png) |
---|
|
1
по
9999
| |
---|
10000
по
19999
| |
---|
20000+
| |
---|
|