UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического
описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый
стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для
определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в
средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Использование
Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов
системного проектирования и отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий
(таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение, и больше сконцентрироваться на проектировании
и архитектуре.
История
В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка
объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем и Рамбо Object-Modeling
Technique, (OMT). OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена
предварительная версия 0.8 унифицированного метода Unified Method. Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор
метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа
требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.
На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.
На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как
Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation,
Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе
1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.
Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно в июне 1999, сентябре 2001 и марте 2003 года.
Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и
расширена для поддержки методологии Model Driven Development — MDD (англ.). Последняя версия UML 2.3 опубликована в мае
2010 года.
UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.
Диаграммы
В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
|
Structure Diagrams:
- Class diagram
- Component diagram
- Composite structure diagram
- Deployment diagram
- Object diagram
- Package diagram
- Profile diagram (UML2.2)
Behavior Diagrams:
- Activity diagram
- State Machine diagram
- Use case diagram
- Interaction Diagrams:
- Communication diagram (UML2.0) / Collaboration (UML1.x)
- Interaction overview diagram (UML2.0)
- Sequence diagram
- Timing diagram (UML2.0)
|
Структурные диаграммы:
- Классов
- Компонентов
- Композитной/составной структуры
- Развёртывания
- Объектов
- Пакетов
- Профилей (UML2.2)
Диаграммы поведения:
- Деятельности
- Состояний
- Вариантов использования
- Диаграммы взаимодействия:
- Коммуникации (UML2.0) / Кооперации (UML1.x)
- Обзора взаимодействия (UML2.0)
- Последовательности
- Синхронизации (UML2.0)
|
Структуру диаграмм 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) — альтернативное представление диаграммы последовательности, явным образом показывающее
изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
Преимущества UML
- UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам
программирования на современных объектно ориентированных языках;
- UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
- Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
- UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере
программной инженерии;
- UML получил широкое распространение и динамично развивается.
Критика
Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:
- Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически
неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают
больше «разработанных-комитетом» компромиссов.
- Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений —
формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками
формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные.
Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за
уникального трактования спецификаций.
- Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство
насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
- Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс,
«The code is the design» («Код и есть проект»).[2],[3]. В соответствии с этим мнением, существует потребность в лучшем способе написания ПО;
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-469-00599-2
