Что такое UML?

Что такое UML?

Unified Modeling Language — это открытый стандарт графической нотации для разработки систем, предложенный Объединенной группой по управлению объектами. Нотация основана на работах Бука, Румбау, Якобсона. UML — это язык моделирования, предназначенный для выражения и проектирования документов, особенно полезный для проектирования, ориентированного на объекты. Язык может использоваться от общего начального проектирования до очень детального проектирования на всех этапах жизненного цикла разработки программного обеспечения. Определение UML приведено ниже:

  • Unified Modeling Language ( UML ) — это графический язык для моделирования и разработки программных систем. Диаграммы UML становятся общим продуктом, который используют разработчики для обсуждения всех этапов разработки программного обеспечения — от анализа требований, проектирования до реализации. Цель заключается в моделировании программной системы до её создания.
  • Цитата: «Unified Modeling Language (UML) — это семейство графических нотаций, основанных на единой метамодели, которые помогают описывать и проектировать программные системы, особенно системы, созданные с использованием объектно-ориентированного (OO) стиля». [Мартин Фаулер — UML Distilled] с. 1.

 Почему UML?

По мере роста размера и сложности архитектур программного обеспечения возрастает потребность в моделях программного обеспечения. UML — это доминирующий язык моделирования в индустрии программного обеспечения. В настоящее время он является фактическим стандартом, принятым Объединённой группой по управлению объектами — крупнейшим консорциумом в мире, занимающимся программным обеспечением. Сложно найти проект программного обеспечения с более чем десятью разработчиками, в котором не использовался бы UML для описания архитектуры.

Вот ещё несколько фактов, касающихся использования UML в нашем процессе разработки программного обеспечения:

  • Программное обеспечение становится всё более сложным: довольно старая версия Windows XP содержит более 40 миллионов строк кода.
  • Один программист не может полностью управлять таким объёмом кода.
  • Код не всегда легко понять разработчикам, которые его не писали.
  • Нам нужны более простые представления сложных систем: моделирование — это способ справляться со сложностью.

Что такое модель?

  • Модель — это абстракция реального объекта, в которой опущены детали.
  • «Совокупность всех элементов, описывающих вашу систему, включая их взаимосвязи, составляет вашу модель». (Расс и Хэмилтон 12).

Когда мы используем UML для создания моделей системы до начала написания кода, они представляют проблему в упрощённой форме. Они предоставляют структуру для решения задач. Они помогают понять, как можно подойти к решению текущей проблемы. Они также позволяют экспериментировать с различными решениями. Поскольку модели создаются до фактической разработки системы, мы можем понять различные возможности, проблемы, варианты и т.д. Это также приводит к снижению затрат на разработку. Поскольку время не будет тратиться на пробные и ошибочные попытки, продукт будет готов быстрее. Модели также помогают управлять сложностью проблемы, что облегчает планирование разработки, распределение ресурсов, таких как компьютеры, программисты, тестировщики.

Что UML НЕ ЯВЛЯЕТСЯ?

  • UML — это не нотация, а язык.
  • UML не принадлежит никому. Он открыт для использования любым желающим. Он не является проприетарным.
  • UML — это не процесс и не метод.
  • UML поощряет использование объектно-ориентированных методов и итеративных жизненных циклов разработки программного обеспечения.
  • UML не сложен. Он объёмный, но не нужно знать его полностью. Также нет необходимости использовать или понимать каждую мелочь в нём.
  • UML не занимает много времени. При правильном использовании UML снижает затраты на разработку. В то же время он даёт преимущества в простоте понимания и коммуникации, повышении производительности и улучшении качества.
  • UML не ограничен. Он достаточно гибкий, чтобы позволять использовать новый словарь (концепции, слова и термины), свойства (дополнительная информация о словах) и семантику (правила языка), необходимые для конкретной области.

Цель UML

  • Визуальный язык моделирования, а не визуальный язык программирования. Хотя некоторые инструменты моделирования имеют генераторы кода, а некоторые могут выполнять обратную инженерию моделей из кода.
  • Он предназначен для создания диаграмм, которые могут поддерживать процесс разработки программного обеспечения, однако UML НЕ является процессом разработки программного обеспечения или методом разработки. Поэтому UML независим от процесса.
  • Стандартный язык для создания чертежей программного обеспечения.
  • Средство коммуникации.
  • Язык для документирования требований, архитектуры, тестов, планирования проектов и т.д…
  • Он предназначен для программных систем, но может моделировать и другие системы.
  • Он предназначен для поддержки процесса разработки на основе объектов.
  • Он может отображать как статические структуры, так и динамическое поведение системы.
  • Диаграммы UML могут помочь заинтересованным сторонам понять, обсудить и согласиться с требованиями.
  • Диаграммы UML могут помочь абстрагировать сложные процессы до уровня, который легче понять.
  • Диаграммы UML помогают облегчить решение проблем.

Что предоставляет язык моделирования?

  • Элементы модели: Концепции и семантика
  • Нотация: Визуальное отображение элементов модели
  • Руководящие принципы: Подсказки и рекомендации по использованию элементов в нотации

Краткая история

В конце 80-х годов, когда мы начали заниматься моделированием, существовало множество различных методологий. И каждая методология имела свою нотацию. Проблема заключалась в том, что если разные люди использовали разные нотации, в какой-то момент кто-то должен был выполнить перевод. Часто один символ означал одно в одной нотации, и совершенно другое в другой. В 1991 году все начали выпускать книги. Грейди Буч выпустил свой первый издание. Ивар Якобсон представил свою версию, а Джим Румбау придумал свою методологию OMT. Каждая книга имела свои сильные и слабые стороны. OMT был очень силен в анализе, но слаб в проектировании. Методология Буча была сильнее в проектировании, но слабее в анализе. А Objectory Ивара Якобсона отлично справлялась с пользовательским опытом, что ни Буч, ни OMT в то время не учитывали. В 1994 году Буч и Якобсон объединили свои методы, а в 1995 году к ним присоединился Румбау. UML 1.1 была опубликована в 1997 году OMG, включая вклад других, например, Юрдена. Версия UML v2.x — самая актуальная версия.

Сроки выпуска

  • 1995 – UML 0.8
  • 1996 – UML 0.9 – Трое друзей
  • 1997 – OMG берет на себя.
  • 1997 – OMG UML 1.1
  • 1998 – OMG UML 1.2
  • 1999 – OMG UML 1.3
  • 2001 – OMG UML 1.4
  • 2003 – OMG UML 1.5
  • 2003 – OMG UML 2.0 – Принята
  • 2005 – OMG UML 2.0 – Финальная версия
  • 2006 – OMG UML 2.1
  • UML2.1.2(11/04/07) – Текущая версия на 27.05.08

Мотивация объединения методов «тремя Амегос»

  • Факт того, что отдельные методы развиваются независимо друг от друга
  • Объединение семантики и нотации для обеспечения стабильности на рынке объектно-ориентированного проектирования
  • Ожидание того, что объединение улучшит ранее существовавшие отдельные методы

Партнёры UML

  • Корпорация Rational Software
  • IBM
  • Hewlett-Packard
  • I-Logix
  • ICON Computing
  • Intellicorp
  • MCI Systemhouse
  • Microsoft
  • ObjecTime
  • Oracle
  • Platinum Technology
  • Taskon
  • Texas Instruments/Sterling Software
  • Unisys

Ввод нотации UML для различных методов до объединения

UML представляет собой объединение нотаций Бука, OMT и Objectory, а также лучших идей ряда других методологов, как показано на приведённом ниже рисунке. Объединив нотации, используемые этими объектно-ориентированными методами, унифицированный язык моделирования создаёт основу для фактического стандарта в области объектно-ориентального анализа и проектирования, основанного на широкой базе опыта пользователей.

Роль нотации

Нотация играет важную роль в любой модели — она является тем, что скрепляет процесс. Нотация имеет три роли:

  • Она служит языком для передачи решений, которые не очевидны или не могут быть выведены из самого кода.
  • Она обеспечивает семантику, достаточно богатую, чтобы зафиксировать все важные стратегические и тактические решения.
  • Она предлагает форму, достаточно конкретную, чтобы люди могли рассуждать, а инструменты — манипулировать ею.

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

Преимущества UML

UML может быть применён к разнообразнымобласти применения (например, банки, финансы, интернет, аэрокосмическая промышленность, здравоохранение и т.д.) Может использоваться со всеми основными объектами и компонентами методы разработки программного обеспечения и для различных платформы реализации.

  • Вы точно знаете, что получаете
  • Вы снизите затраты на разработку
  •  Ваше программное обеспечение будет вести себя так, как вы ожидаете. Меньше сюрпризов
  •  Правильные решения принимаются до того, как вам будет предоставлен плохо написанный код. Меньшие общие затраты
  • Мы можем разрабатывать более эффективные по памяти и процессору системы
  • Затраты на сопровождение системы будут ниже. Меньше повторного обучения
  • Работа с новым разработчиком будет проще.
  • Общение с программистами и внешними подрядчиками будет более эффективным.

Модели UML 4 + 1

UML состоит из следующих четырех видов системы, находящейся в разработке (см. рис. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:

  • Вид использования: показывает функциональность системы с точки зрения внешних участников; описывается с помощью диаграмм случаев использования и время от времени — диаграмм деятельности.
  • Логический вид: показывает, как эта функциональность спроектирована внутри системы, с точки зрения статической структуры и динамического поведения системы; описывается с помощью диаграмм классов и объектов (статическая модель) и диаграмм переходов состояний, последовательностей, взаимодействий и деятельности (динамическая модель)
  • Вид компонентов: показывает организацию программных компонентов; описывается с помощью диаграмм компонентов.
  • Вид развертывания: показывает физическую конфигурацию (развертывание) узлов выполнения в компьютерах и устройствах, а также компонентов, процессов и объектов, которые на них находятся; описывается с помощью диаграмм развертывания.
  • Вид процессов: показывает параллельный аспект системы в режиме выполнения, такие как задачи, потоки, процессы и взаимодействия, а также решает проблемы связи и синхронизации этих потоков; описывается с помощью динамических диаграмм (диаграммы переходов состояний, последовательностей, взаимодействий и деятельности) и диаграмм реализации (диаграммы компонентов и развертывания).

4+1 architectural view model

Каждая система состоит из статической и динамической модели. Статическая модель отображается на диаграммах классов и объектов. Однако она мало что раскрывает о поведении системы. Поведение системы графически фиксируется с помощью сценариев (т.е. диаграмм случаев использования), диаграмм последовательностей, диаграмм переходов состояний и диаграмм деятельности. Эти элементы составляют динамическую модель системы. Поведение системы — это общее поведение всех объектов, входящих в систему.

Если мы хотим сопоставить приведенные пять взглядов с итеративными фазами жизненного цикла, показанными на рис. 3, мы можем сказать следующее:

  • Объектно-ориентированный анализ (OOA), который разрабатывает модель требований пользователей с точки зрения пользователя, соответствует виду использования.
  • Объектно-ориентированный дизайн (OOD) добавляет детали и решения по проектированию (с точки зрения разработчика) к анализу и соответствует логическому виду.
  • Наконец, реализация или объектно-ориентированное программирование (ООП) соответствует процессу, развертыванию и компонентному виду.

Диаграммы UML 2

UML имеет несколько различных типов диаграмм, которые могут использоваться для описания модели с разных точек зрения. Существует два широких класса диаграмм, которые затем делятся на подкатегории:

  • Структурные диаграммы –структурные диаграммыпредставляют статическую часть системы. Эти статические аспекты представляют те части диаграммы, которые формируют основную структуру и, следовательно, стабильны. Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами.
  • Диаграммы поведения – любая система может иметь два аспекта: статический и динамический. Поэтому модель считается полной, когда оба аспекта полностью охвачены.
    Диаграммы поведения в основном фиксируют динамический аспект системы. Динамический аспект можно дополнительно описать как изменяющиеся/движущиеся части системы.

UML Diagram Types

Структурные диаграммы

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

Диаграммы поведения

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

Диаграммы типов взаимодействий – взаимодействия организационных частей модели.

  • Диаграмма последовательности – это диаграмма взаимодействия и потока сообщений между объектами и относительного порядка времени сообщений
  • Диаграмма коммуникации(также известна как диаграммы сотрудничества UML1) – это диаграмма того, как системы взаимодействуют для выполнения задачи и связей, которые должны существовать между системами. Диаграмма сотрудничества является результатом преобразования диаграммы последовательности с описанием её взаимодействия с диаграммой классов. Вкратце, эта диаграмма показывает поток сообщений между объектами и основные ассоциации (связи) между классами
  • Диаграмма временных интервалов – это диаграмма, которая исследует поведение одного или нескольких объектов в течение заданного периода времени.
  • Диаграмма обзора взаимодействий – это диаграмма взаимодействия и управления потоком между диаграммами взаимодействий (диаграмма последовательности, диаграмма коммуникации, диаграмма временных интервалов, диаграмма обзора взаимодействий).

Профиль UML

Профиль UML — это не совсем диаграмма, а профиль, предназначенный для описания расширений и подмножеств UML. Подмножества описываются с помощью языка ограничений объектов (OCL). Расширения создаются путем определения стереотипов, которые являются метками, которые могут быть применены к любому элементу модели. Например, мы можем пометить класс как «персистентный» и использовать эту метку для идентификации класса, экземпляры которого хранятся после окончания времени выполнения системы. Неформально — и это идеологически некорректно — профиль представляет собой любое множество расширений и подмножеств UML, независимо от того, описаны ли они с помощью этих механизмов или нет. Формально профиль — это определения OCL и стереотипов, описывающие правила, которые в UML 2 захватываются в пакете.

Связанные диаграммы для разработки программного обеспечения

В зависимости от различий между методологиями ООАД и эволюции стандартов UML названия диаграмм и их функции могут меняться со временем. Вот некоторые примеры диаграмм и/или рабочих продуктов, которые могут или не могут входить в UML1 или UML2, но могут использоваться в методологиях ООАД:

  • Диаграмма контекста системы
  • Диаграмма связей между сущностями (похожа на диаграмму классов) с концептуальной, логической и физической ERD
  • Анализ устойчивости

Заключение

Мы рассмотрели происхождение и определение UML, чтобы дать простое понимание того, что это такое, и чего может предложить UML. Мы также проанализировали, как мы можем воспользоваться его применением в нашем следующем проекте разработки, и кратко изучили архитектурные взгляды, модели и типы диаграмм, доступные в UML 2. UML — это не процесс, а открытый стандарт визуального моделирования для разработки программных систем. Для успешного проекта необходимы три аспекта: нотация, процесс и инструмент:

 

 

Только нотация – вы можете изучитьнотацию (например, UML), но если вы не знаете, как её использовать (процесс), вероятно, вы не справитесь.

Только процесс – у вас может быть отличный процесс, но если вы не можете передать процесс (нотация), вероятно, вы не справитесь. И наконец

Отсутствие поддержки инструментов – если вы не можете эффективно документировать артефакты своей работы (инструмент), вероятно, вы потратите много времени и в конечном итоге не справитесь.

 

Автоматизированный инструмент UML

Visual Paradigm — это автоматизированный инструмент, который обеспечивает ваш успех в проектах по разработке программного обеспечения с:

  1. Простое редактирование синтаксиса для минимизации необходимости запоминания нотации
  2. Поддержка популярных и наиболее простых процессов и наборов инструментов разработки программного обеспечения по методологии Agile Scrum
  3. Автоматизировано для оптимизации любого размера проекта, отчетов и артефактов продукта в режиме реального времени

Ресурсы UML

  1. Полное руководство по 14 типам диаграмм UML – Cybermedian
    • Это руководство дает обзор 14 типов диаграмм UML, поддерживаемых Community Edition Visual Paradigm. Оно объясняет, как диаграммы UML помогают в визуализации систем, интенсивно использующих программное обеспечение, и описывает функциональность, предоставляемую каждым типом диаграммы. Руководство также подчеркивает универсальность Visual Paradigm в поддержке различных диаграмм UML для различных потребностей моделирования.
  2. Изучите моделирование UML с помощью лучших бесплатных инструментов UML (как онлайн, так и настольных бесплатных программ) – Cybermedian
    • В этой статье рассматриваются преимущества использования Visual Paradigm для моделирования UML, подчеркивая его поддержку последней версии стандарта UML 2.x и широкий спектр типов диаграмм. Также упоминаются возможности интеграции инструмента с популярными платформами разработки и его широкое распространение в академической и промышленной сферах.
  3. Обучение на примерах: диаграммы состояний UML – Cybermedian
    • Этот ресурс сосредоточен на диаграммах состояний UML и рекомендует Visual Paradigm как идеальный инструмент для создания этих диаграмм. Он подробно рассматривает, как диаграммы состояний могут моделировать динамическое поведение системы, и подчеркивает интеграцию Visual Paradigm с инструментами и платформами разработки.
  4. Диаграммы UML: Полное руководство – Cybermedian
    • Это всестороннее руководство объясняет важность диаграмм UML в разработке программного обеспечения и то, как Visual Paradigm поддерживает различные типы диаграмм UML. Оно охватывает структурные, поведенческие и взаимодействующие диаграммы, предоставляя информацию о том, как можно использовать Visual Paradigm для создания эффективных моделей UML.
  5. БЕСПЛАТНЫЙ онлайн-инструмент для диаграмм UML – Cybermedian
    • В этой статье представлен Visual Paradigm Online (VP Online) Express Edition — бесплатный онлайн-инструмент для создания диаграмм UML. Отмечается простота использования инструмента, отсутствие ограничений и совместимость с различными веб-браузерами, что делает его доступным вариантом для создания диаграмм UML в личных и некоммерческих целях.
  6. Понимание диаграмм временных интервалов UML: Полное руководство – Cybermedian
    • Это руководство объясняет диаграммы временных интервалов UML и их значение в системах реального времени. Рассматривается, как можно использовать Visual Paradigm для создания этих диаграмм, с акцентом на визуальное представление ограничений по времени и продолжительности в системе.
  7. Полное руководство по диаграммам UML 2.5 – Cybermedian
    • Это руководство дает обзор диаграмм UML 2.5 и выделяет Visual Paradigm как лучший выбор для комплексного моделирования. Рассматривается универсальность инструмента, удобный интерфейс и мощные возможности генерации кода, что делает его подходящим для специалистов различных отраслей.
  8. Полное руководство по диаграмме классов UML – Cybermedian
    • Это руководство сосредоточено на диаграммах классов UML и о том, как Visual Paradigm поддерживает их создание. Рассматривается широкое распространение инструмента в академической среде и его применение при проектировании и анализе систем и баз данных. Также упоминается наличие примеров и шаблонов для быстрого старта моделирования UML.
  9. Учебник по диаграммам пакетов UML с использованием Visual Paradigm – Cybermedian
    • Этот учебник описывает шаги по созданию диаграммы пакетов UML с использованием Visual Paradigm. Объясняется важность диаграмм пакетов для организации крупных систем и приводится пошаговое руководство по их созданию с помощью Visual Paradigm.
  10. Полное руководство по визуальному моделированию для разработки программного обеспечения по методологии Agile – Cybermedian
    • Это руководство обсуждает роль инструментов UML в разработке программного обеспечения по методологии Agile и выделяет Visual Paradigm как популярный выбор. Объясняется, как Visual Paradigm предоставляет удобный интерфейс и функции, такие как проверка, генерация кода и обратная инженерия, для улучшения процесса моделирования.

 

 

 

Leave a Reply