| На главную | О проекте | Контакты |
www.Russika.Ru
Термин в Энциклопедическом Фонде

Язык моделирования UML

UML (англ. Unified Modeling Language - Унифицированный Язык Моделирования) - графический язык моделирования общего назначения, предназначенный для визуализации, спецификации, конструирования и документирования артефактов программных системы.
По словам Мартина Фаулера (Martin Fowler), UML возник как стандарт после многолетних интеллектуальных и бюрократических споров в сообществе приверженцев объектно-ориентированного проектирования.

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

История создания
В 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
Структурные сущности
Структурные сущности являются основными блоками языка.
Класс (Class) - описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции (рис. 1 а).
Интерфейс (Interface) - совокупность операций, определяющих набор методов, предоставляемых классом или его компонентами. Графически изображается в виде круга, под которым пишется его имя (рис. 1 б).
Кооперация (Collaboration) - совокупность ролей и других элементов, которые, работая совместно, производят некоторый совместный эффект. Графически изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только его имя (рис. 1 в).
Прецедент (Use case) - описание последовательности выполняемых системой действий, производящая наблюдаемый результат, значимый для какого-то определенного актера (Actor). Применяется для структурирования поведенческих сущностей модели. Графически изображается в виде эллипса, ограниченного непрерывной линией, в который обычно заключено только его имя (рис. 1 г).
Активный класс (Active class) - класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется с деятельностью других элементов. Графически изображается в виде как простой класс, но ограничивающий прямоугольник рисуется жирной линией (рис. 1 д).
Компонент (Component) - физическая заменяемая часть системы, соответствующая некоторому набору интерфейсов и обеспечивающая его реализацию. Графически изображается в виде прямоугольника с вкладками, содержащего обычно только имя (рис. 2 а).
Узел (Node) - элемент физической системы, который существует во время функционирование программного комплекса и представляет собой вычислительный ресурс. Графически изображается в виде куба, обычно содержащего только имя (рис. 2 б).

Поведенческие сущности
Поведенческие сущности являются динамическими составляющими модели UML
Взаимодействие (Interaction) - поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. Графически изображается в виде стрелки, над которой практически всегда сверху пишется имя соответствующей операции (рис. 2 в).
Автомат (State machine) - это алгоритм поведения, определяющих последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а так же реакции на эти события. Графически изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, подсостояния (рис. 2 г).

Группирующие сущности
Группирующие сущности являются организующими частями модели UML.
Пакет (Packages) - представляют собой универсальный механизм организации элементов в группу. В пакет можно поместить структурные, поведенческие, и другие группирующие
сущности. В отличие от компонентов, существующих во время работы программы, пакеты существуют только во время разработки и носят чисто концептуальный характер. Графически изображается в виде папки с закладкой, обычно содержащей только имя, иногда - содержимое (рис. 2 д)
Существуют так же вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

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

Отношения UML
Зависимость (Dependency) - семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может отразиться на семантике другой, зависимой. Графически изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку (рис. 3 б).
Ассоциация (Association) - структурное отношение, описывающее совокупность связей. Графически изображается в виде прямой линии, иногда завершающуюся стрелкой или содержащую метку, рядом с которой могут присутствовать дополнительные обозначения (рис. 3 в).
Обобщение (Generalization) - это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка - Child) можно подставить вместо объектов обобщенного элемента (родителя, предка - Parent). Графически изображается в виде линии с незакрашенной стрелкой, указывающей на родителя (рис. 3 г).
Реализация (Realization) - отношение между спецификацией и ее программной реализацией, указание на то, что поведение наследуется без структуры. Графически изображается в виде пунктирной линии с незакрашенной стрелкой (рис. 3 д).
В UML также существуют их варианты: уточнение (Refinement), трассировка (Trace), включение (Include), расширение (Extend).

Диаграммы UML
Диаграмма классов (Class diagram) - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Диаграмма объектов (Object diagram) - демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма последовательности (Sequence diagram) - диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграмма коммуникации (Communication diagram, диаграмма кооперации, collaboration diagram) - диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) - диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.
Диаграмма деятельности (Activity diagram) - диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (Activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов - вложенных видов деятельности и отдельных, соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Диаграмма компонентов (Component diagram) - статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма развёртывания (Deployment diagram) - служит для моделирования работающих узлов и артефактов, развёрнутых на них. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
Диаграмма композитной/составной структуры (Composite structure diagram) - статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Диаграмма пакетов (Package diagram) - структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма вариантов использования (Use case diagram) - диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования. Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграмма обзора взаимодействия (Interaction overview diagram) - разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
Диаграмма синхронизации (Timing diagram) - альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

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

Недостатки
Избыточность языка. Включает много избыточных или практически неиспользуемых диаграмм и конструкций.
Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений - формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные.
Только код отражает код. Ещё одно мнение - что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, "The code is the design" ("Код и есть проект"). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки - термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
Пытается быть всем для всех. UML - это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

Редакторы
Dia
MS Visio
Umbrello

Используемые источники
1. Мартин Фаулер. UML. Основы, 3 е издание. Спб Символ 2005 г.
2. Джим Арлоу и Айла Нейштадт.. UML 2 и Унифицированный процесс, 2 е издание. Спб Символ 2008 г.
3. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя. Спб ДМК пресс 2000 г.
4. http://ru.wikipedia.org
Энциклопедический Фонд
 
Бани под ключ - Строительство деревянных домов и бань. Информация об услугах. (stroymir53.ru)