UML означаетУнифицированный язык моделирования. Это стандартизированный язык моделирования, состоящий из интегрированного набора диаграмм, разработанных для помощи системным и программным разработчикам в спецификации, визуализации, построении и документировании артефактов программных систем, а также для моделирования бизнеса и других не программных систем.

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

Истоки UML

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

UML возник в результате объединения трёх ведущих объектно-ориентированных нотаций моделирования:

1. Метод моделирования объектов (OMT) [Джеймс Румбау 1991] – наиболее подходит для анализа и информационных систем, интенсивно использующих данные.
2. Booch [Грейди Буч 1994] – очень сильный в проектировании и реализации. Грейди Буч активно работал с языкомAda и был основным участником объектно-ориентированной разработки этого языка. Несмотря на то, что метод Буча был мощным, его нотация не была особенно популярной (много облачных форм в его моделях — не очень аккуратно).
3. OOSE (Объектно-ориентированная инженерия программного обеспечения [Ивар Якобсон 1992]) — характеризуется моделью, называемой Use Cases. Use Cases — это мощный способ понимания поведения всей системы (область, в которой ОО традиционно была слабой).

В 1994 году мир программного обеспечения был потрясён, когда Джим Румбау, создатель OMT, покинул General Electric и присоединился к Грейди Бучу в Rational Software. Сотрудничество было направлено на объединение их идей в едином методе (рабочее название — «Единый метод»).

К 1995 году Ивар Якобсон, создатель OOSE, также присоединился к Rational, и его идеи (в частности, концепция «Use Cases») были интегрированы в новый единый метод — теперь называемый Unified Modeling Language 1. Команда Румбау, Буча и Якобсона дружелюбно называлась «Тремя приятелями».

UML также был influenced другими объектно-ориентированными нотациями того времени:

• Меллор и Шлаер [1998]
• Коад и Юрдон [1995]
• Вирфс-Брок [1990]
• Мартин и Одэлл [1992]

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

История UML

1. В 1996 годуГруппа управления объектами (OMG) выпустила первый запрос на предложение (RFP), который стал катализатором для сотрудничества этих организаций в ответе на совместный запрос на предложение.
2. Rational создала консорциум UML Partners вместе с несколькими организациями, готовыми выделить ресурсы для разработки сильной версии UML 1.0. К основным участникам разработки UML 1.0 относились:
   • Корпорация Digital Equipment
   • Hewlett-Packard
   • I-Logix
   • IntelliCorp
   • IBM
   • ICON Computing
   • MCI Systemhouse
   • Microsoft
   • Oracle
   • Rational Software
   • Texas Instruments
   • Unisys
3. Это сотрудничество привело к созданию UML 1.0 — хорошо определенного, выразительного, мощного и универсального языка моделирования. Он был представлен в OMG в качестве первоначального ответа на запрос предложений в январе 1997 года.
4. В январе 1997 года IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies и Softeam также представили отдельные ответы на запрос предложений в OMG. Эти компании присоединились к партнерам UML, чтобы внести свои идеи, и совместно разработали обновленный ответ по UML 1.1. UML 1.1 был направлен на улучшение ясности семантики UML 1.0 и интеграцию вкладов новых партнеров. Он был представлен в OMG на рассмотрение и принят осенью 1997 года. Версии развивались от 1.1 до 1.5, за которыми последовали UML 2.0 через 2.5 (текущая версия — UML 2.5).

Почему UML?

По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала технологии для автоматизации производства программного обеспечения и повышения его качества при одновременном снижении затрат и сокращении времени выхода на рынок. К таким технологиям относятся технология компонентов, визуальное программирование, шаблоны и фреймворки. Бизнес также ищет способы управления сложностью по мере роста масштабов и объема деятельности. В частности, они осознают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость. Более того, развитие Всемирной паутины, хотя и упростило некоторые аспекты, усугубило эти архитектурные проблемы. Unified Modeling Language (UML) был разработан для удовлетворения этих потребностей.

1. Предоставить пользователям готовый к использованию, выразительный визуальный язык моделирования для разработки и обмена значимыми моделями.
2. Предоставить механизмы расширяемости и специализации для расширения основных концепций.
3. Быть независимым от конкретных языков программирования и процессов разработки.
4. Предоставить формальную основу для понимания языка моделирования.
5. Способствовать росту рынка инструментов, основанных на объектно-ориентированном подходе.
6. Поддерживать концепции высокого уровня разработки, такие как взаимодействия, фреймворки, шаблоны и компоненты.
7. Интегрировать лучшие практики.

UML — Обзор

Прежде чем погрузиться в теорию UML, давайте кратко познакомимся с основными понятиями UML.

Первое, на что следует обратить внимание в UML, — это то, что существует множество различных диаграмм (моделей), с которыми нужно освоиться. Причина этого заключается в том, что система может рассматриваться с разных точек зрения. Разработка программного обеспечения вовлекает множество заинтересованных сторон.

Например:

• Аналитики
• Дизайнеры
• Программисты
• Тестировщики
• Контроль качества
• Клиенты
• Технические авторы

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

Вот краткий обзор каждого из 13 диаграмм, показанных в структуре диаграмм UML 2:

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

• Диаграмма классов
• Диаграмма компонентов
• Диаграмма развертывания
• Диаграмма объектов
• Диаграмма пакетов
• Диаграмма композитной структуры
• Диаграмма профиля

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

• Диаграмма случаев использования
• Диаграмма деятельности
• Диаграмма машины состояний
• Диаграмма последовательности
• Диаграмма коммуникации
• Диаграмма обзора взаимодействий
• Диаграмма временных интервалов

Что такое диаграмма классов?

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

Связи

Существует три основных важных отношения:

1. Ассоциация – указывает на связь между экземплярами типов (например, человек работает в компании, компания имеет несколько офисов).
2. Наследование – наиболее очевидное дополнение к диаграммам ER, используемым в ОО. Оно напрямую соответствует наследованию в проектировании ОО.
3. Агрегация – форма композиции объектов в объектно-ориентированном проектировании.

Пример диаграммы классов

Для получения дополнительной информации о диаграммах классов прочитайте статью Что такое диаграмма классов?

Что такое диаграмма компонентов?

В унифицированном языке моделирования диаграмма компонентов показывает, как компоненты соединяются для создания более крупных компонентов или программных систем. Она иллюстрирует архитектуру программных компонентов и их зависимости. К этим программным компонентам относятся компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.

Пример диаграммы компонентов

Для получения дополнительной информации о диаграммах компонентов прочитайте статью Что такое диаграмма компонентов?

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

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

Пример диаграммы развертывания

Для получения дополнительной информации о диаграммах развертывания прочитайте статью Что такое диаграмма развертывания?

Что такое диаграмма объектов?

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

Диаграмма классов против диаграммы объектов – Пример

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

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

Связь между диаграммой классов и диаграммой объектов

Вы создаете «классы» при программировании. Например, в системе онлайн-банкинга вы можете создать классы, такие как «Пользователь», «Счет», «Транзакция» и т.д. В системе управления классом вы можете создать классы, такие как «Учитель», «Студент», «Задание» и т.д. В каждом классе есть атрибуты и операции, которые представляют характеристики и поведение класса. Диаграмма классов — это диаграмма UML, на которой можно визуализировать эти классы, их атрибуты, операции и взаимосвязи между ними.

Диаграмма объектов UML показывает, как экземпляры объектов классов (нарисованные на диаграмме классов UML) «выглядят» в определенном состоянии. Другими словами, диаграмма объектов UML может рассматриваться как экземпляр того, как классы (на диаграмме классов UML) используются в конкретном состоянии.

Если вам не нравятся эти определения, взгляните на примеры диаграмм UML ниже. Я уверен, что вы поймете их различие за секунды.

Пример диаграммы классов

Приведенный ниже пример диаграммы классов представляет два класса — User и Attachment. Пользователь может загружать несколько вложений, поэтому два класса связаны ассоциацией с множественностью 0…* на стороне Attachment.

Пример диаграммы объектов

Приведенный ниже пример диаграммы объектов показывает, как экземпляры объектов классов User и Attachment «выглядят» в тот момент, когда Питер (то есть пользователь) пытается загрузить два вложения. Таким образом, существует два экземпляра двух вложений, которые необходимо загрузить.

Для получения дополнительной информации о диаграммах объектов прочитайте статью Что такое диаграмма объектов?

Что такое диаграмма пакетов?

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

Пример диаграммы пакетов

Для получения дополнительной информации о диаграммах пакетов прочитайте статью Что такое диаграмма пакетов?

Что такое диаграмма композитной структуры?

Диаграммы композитной структуры — один из новых элементов, добавленных в UML 2.0. Диаграмма композитной структуры похожа на диаграмму классов и является типом диаграммы компонентов, в основном используемым для моделирования системы с микро-точки зрения, но она отображает внутреннюю структуру отдельной части, а не всего класса. Это статическая диаграмма структуры, которая показывает внутреннюю структуру класса и взаимодействия, которые возможны благодаря этой структуре.

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

Пример диаграммы композитной структуры

Для получения дополнительной информации о диаграммах композитной структуры прочитайте статью Что такое диаграмма композитной структуры?

Что такое диаграмма профиля?

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

Пример диаграммы профиля

Для получения дополнительной информации о диаграммах профиля прочитайте статью Что такое диаграмма профиля в UML?

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

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

Представьте модель вариантов использования как меню, как то, что вы можете найти в ресторане. Глядя на меню, вы можете увидеть, какие блюда доступны, отдельные блюда и их цены. Вы также знаете, какую кухню подаёт ресторан: итальянскую, мексиканскую, китайскую и т.д. Глядя на меню, вы получаете общее представление о том, какой опыт обеда вас ждёт в этом ресторане. Меню на самом деле «имитирует» поведение ресторана.

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

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

Для получения дополнительной информации о диаграммах вариантов использования прочитайте статью Что такое диаграмма вариантов использования?

Что такое диаграмма деятельности?

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

Пример диаграммы деятельности

Для получения дополнительной информации о диаграммах деятельности прочитайте статью Что такое диаграмма деятельности?

Что такое диаграмма состояний?

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

Пример диаграммы машины состояний

Для получения дополнительной информации о диаграммах машин состояний прочитайте статью Что такое диаграмма машины состояний?

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

Последовательная диаграмма моделирует взаимодействие объектов в соответствии с временной последовательностью. Она показывает, как объекты взаимодействуют друг с другом в конкретной сценарии использования. Благодаря продвинутым возможностям визуального моделирования, вы можете создавать сложные последовательные диаграммы всего за несколько кликов. Кроме того, некоторые инструменты моделирования (например, Visual Paradigm) могут генерировать последовательные диаграммы на основе потока событий, которые вы определили в описаниях сценариев использования.

Пример последовательной диаграммы

Для получения дополнительной информации о последовательных диаграммах прочитайте статью Что такое последовательная диаграмма?

Что такое диаграмма взаимодействия?

Подобно последовательной диаграмме, диаграмма взаимодействия также используется для моделирования динамического поведения сценария использования. В отличие от последовательных диаграмм, диаграммы взаимодействия больше акцентируют внимание на отображении взаимодействия объектов, а не на временной последовательности. Они семантически эквивалентны, поэтому некоторые инструменты моделирования (например, Visual Paradigm) позволяют генерировать одну диаграмму из другой.

Пример диаграммы взаимодействия

Для получения дополнительной информации о диаграммах взаимодействия прочитайте статью Что такое диаграмма взаимодействия?

Что такое диаграмма обзора взаимодействия?

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

Пример диаграммы обзора взаимодействия

Для получения дополнительной информации о диаграммах обзора взаимодействия прочитайте статью Что такое диаграмма обзора взаимодействия?

Что такое временная диаграмма?

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

Пример временной диаграммы

Для получения дополнительной информации о временных диаграммах прочитайте статью Что такое временная диаграмма?

Изучайте UML. Рисуйте UML.

Получите Community Edition Visual Paradigm — бесплатный инструмент UML, который помогает быстрее и эффективнее изучать UML. Community Edition Visual Paradigm поддерживает все типы диаграмм UML. Ее награждаемый модельер UML интуитивно понятен и прост в использовании.

Бесплатная загрузка

Словарь и терминология UML

• Абстрактный класс – Класс, который никогда не создается. Экземпляры этого класса никогда не существуют.
• Актер – Объект или человек, инициирующий события, связанные с системой.
• Деятельность: Шаг или действие в диаграмме деятельности. Представляет операцию, выполняемую системой или актером.
• Диаграмма деятельности: Улучшенная блок-схема, показывающая шаги и решения в процессе, а также параллельные операции, такие как алгоритм или бизнес-процесс.
• Агрегация – Является частью другого класса. Обозначается пустым ромбом рядом с содержащим классом на диаграмме.
• Артефакт – Документ, описывающий результат шага в процессе проектирования. Описание может быть графическим, текстовым или их комбинацией.
• Ассоциация – Связь между двумя элементами в модели. Это может представлять собой переменную-член в коде, связь между записью о персонале и человеке, который она представляет, связь между двумя классами работников или любым подобным отношением. По умолчанию оба элемента в ассоциации знают друг о друге и равны. Ассоциация также может быть навигируемой, что означает, что исходный элемент знает о целевом, но не наоборот.
• Класс ассоциации: Класс, представляющий ассоциацию между двумя другими классами и добавляющий к ней информацию.
• Атрибут – Характеристика объекта, которая может использоваться для ссылки на другие объекты или хранения информации о состоянии объекта.
• Базовый класс: Класс, определяющий атрибуты и операции, наследуемые подклассами через отношение обобщения.
• Ветвь: Точка принятия решения на диаграмме деятельности. Из ветви исходят несколько переходов, каждый со своим условием-ограничением. Когда управление достигает ветви, должно быть истинным ровно одно условие-ограничение, и управление следует соответствующему переходу.
• Класс: Категория похожих объектов, все описываемые одинаковыми атрибутами и операциями, и все совместимые по присваиванию.
• Диаграмма классов – Показывает классы в системе и отношения между ними.
• Классификатор: Элемент UML, имеющий атрибуты и операции. Конкретно: актеры, классы и интерфейсы.
• Сотрудничество: Отношение между двумя объектами на диаграмме взаимодействия, указывающее, что сообщения могут передаваться между объектами в обоих направлениях.
• Диаграмма взаимодействия – Диаграмма, показывающая, как выполняется операция, с акцентом на роли объектов.
• Компонент: Развертываемый элемент кода в системе.
• Диаграмма компонентов: Диаграмма, показывающая отношения между различными компонентами и интерфейсами.
• Концепция – Существительное или абстрактная концепция, которая должна быть включена в модель домена.
• Фаза построения – Третья фаза процесса Rational Unified Process, в ходе которой в построенную систему встраиваются несколько функциональных итераций. Именно здесь проходит основная часть работы.
• Зависимость: Связь, указывающая, что один классификатор знает о характеристиках и операциях другого классификатора, но не связан напрямую с какими-либо экземплярами второго классификатора.
• Диаграмма развертывания: Диаграмма, показывающая отношения между различными процессорами.
• Область – Часть универсума дискурса, с которой взаимодействует система.
• Фаза уточнения – Вторая фаза процесса Rational Unified Process, позволяющая дополнительное планирование проекта, включая итерации в фазе построения.
• Элемент: Любой элемент, отображаемый в модели.
• Инкапсуляция – Данные внутри объекта являются приватными.
• Обобщение – Указывает, что один класс является подклассом другого (суперкласса). Пустой стрелка указывает на суперкласс.
• Событие: В диаграмме состояний это представляет сигнал, событие или вход, вызывающий действие системы или изменение состояния.
• Конечное состояние: В диаграмме состояний или диаграмме деятельности это представляет точку, в которой диаграмма завершается.
• Разветвление: Точка в диаграмме деятельности, в которой начинаются несколько параллельных потоков управления.
• Обобщение: Связь наследования, при которой подкласс наследует и расширяет атрибуты и операции базового класса.
• GoF – Паттерны проектирования «Четыре гнома».
• Высокая связанность – Оценочный паттерн GRASP, который обеспечивает, что класс не слишком сложен и не выполняет нерелевантные функции.
• Низкая связанность – Оценочный паттерн GRASP, который измеряет степень, в которой один класс зависит от или связан с другим классом.
• Фаза начала – Первая фаза процесса Rational Unified Process, связанная с первоначальным концептуализированием и началом проекта.
• Наследование – Подкласс наследует атрибуты или особенности от своего родительского (суперкласса) класса. Эти атрибуты могут быть переопределены в подклассе.
• Начальное состояние: В диаграмме состояний или диаграмме деятельности это обозначает точку, с которой начинается диаграмма.
• Экземпляр – Объект является экземпляром класса. Класс выступает как шаблон для создания объектов. Можно создать любое количество экземпляров класса.
• Интерфейс: Классификатор, определяющий атрибуты и операции, образующие поведенческий контракт. Класс или компонент-поставщик может выбрать реализовать интерфейс (то есть реализовать его атрибуты и операции). Клиентские классы или компоненты могут затем зависеть от интерфейса, используя поставщика, не зная деталей реального класса-поставщика.
• Итерация – Часть мини-проекта, в которой добавляется небольшой фрагмент функциональности. Включает цикл разработки, состоящий из анализа, проектирования и кодирования.
• Соединение: Точка в диаграмме деятельности, где несколько параллельных потоков управления синхронизируются и снова соединяются.
• Член: Атрибут или операция в классификаторе.
• Объединение: Точка в диаграмме деятельности, где различные пути управления сходятся.
• Сообщение – Запрос от одного объекта к другому, в котором запрашивается выполнение какого-либо действия получателем. По сути, это вызов метода в получателе.
• Метод – Функция или процедура в объекте.
• Модель – Центральный элемент UML. Состоит из различных элементов, расположенных в иерархиях с отношениями между элементами.
• Множественность – Отображается рядом с внешним блоком концепции в модели домена и указывает количественную связь объектов с другими объектами.
• Навигация: Указывает, какой конец связи знает о другом конце. Связь может иметь двунаправленную навигацию (каждый конец знает о другом) или одностороннюю навигацию (один конец знает о другом, но не наоборот).
• Нотация – Графическая документация с правилами создания методов анализа и проектирования.
• Примечание: Текстовое комментарий, добавленный к диаграмме для более подробного объяснения диаграммы.
• Объект – В диаграмме деятельности объект, который получает информацию от или предоставляет информацию активности. В диаграмме взаимодействия или последовательности объект, участвующий в сценарии, описанном на диаграмме. В общем случае: экземпляр или пример данного классификатора (Актор, Класс или Интерфейс).
• Пакет – Группа элементов UML, логически относящихся друг к другу.
• Диаграмма пакетов: Диаграмма классов, в которой все элементы являются пакетами и зависимостями.
• Шаблон – Решение проблемы распределения ответственности за взаимодействие объектов. Это названное решение часто возникающей и хорошо известной проблемы.
• Параметр: Параметр операции.
• Полиморфизм – Один и тот же сообщение, разные методы. Также используется как шаблон.
• Приватный: Уровень видимости, применяемый к атрибуту или операции, указывающий, что к члену может получить доступ только код внутри содержащего классификатора.
• Процессор: В диаграмме развертывания это представляет компьютер или другой программируемый устройство, на котором может быть развернут код.
• Защищенный: Уровень видимости, применяемый к атрибуту или операции, указывающий, что к члену может получить доступ только код внутри содержащего классификатора или его подклассов.
• Публичный: Уровень видимости, применяемый к атрибуту или операции, указывающий, что к члену может получить доступ любой код.
• Стрелка направления чтения – Указывает направление связи в модели домена.
• Реализация: Указывает, что компонент или класс реализует данный интерфейс.
• Роль – Используется в модели домена, представляет собой необязательное описание роли, которую играет сущность.
• Диаграмма последовательности: Диаграмма, показывающая существование объектов во времени и сообщения, передаваемые между этими объектами во времени для выполнения некоторого поведения. Диаграмма состояний – диаграмма, показывающая все возможные состояния объекта.
• Состояние: В диаграмме состояний это представляет состояние или условие системы или подсистемы: что она делает в определенный момент времени и какие значения данных она имеет.
• Диаграмма состояний: Диаграмма, показывающая состояния системы или подсистемы, переходы между состояниями и события, вызывающие переходы.
• Статический: Модификатор, применяемый к атрибуту, указывающий, что только одна копия атрибута обобщается всеми экземплярами классификатора. Модификатор, применяемый к операции, указывающий, что операция независима и не работает с конкретным экземпляром классификатора.
• Стереотип: Модификатор, применяемый к элементу модели, указывающий на что-либо, что обычно не может быть выражено в UML. По сути, стереотипы позволяют вам определить свой собственный «диалект» UML.
• Подкласс: Класс, который наследует атрибуты и операции, определенные суперклассом через отношение обобщения.
• Полоса: Элемент в диаграмме деятельности, указывающий, какая часть системы или домена несет ответственность за конкретную деятельность. Все действия в полосе являются ответственностью объекта, компонента или актора, представленного полосой.
• Ограничение времени – Каждая итерация имеет фиксированный временной лимит с конкретной целью.
• Переход: В диаграмме деятельности это представляет поток управления от одной деятельности или ветви или слияния или расщепления или соединения к другой. В диаграмме состояний это представляет изменение от одного состояния к другому.
• Фаза перехода – Последняя фаза процесса Rational Unified Process, в которой пользователи проходят обучение использованию нового систем и система становится доступной для пользователей.
• UML – Unified Modeling Language повышает качество анализа и проектирования программных проектов, позволяя устанавливать более тесные связи между объектами с помощью текстовой и графической документации.
• Случай использования: В диаграмме случаев использования это представляет действие, предпринятое системой в ответ на запрос от актора.
• Диаграмма случаев использования: Диаграмма, показывающая отношения между акторами и случаями использования.
• Видимость: Модификатор для атрибута или операции, указывающий, какой код может получить доступ к члену. Уровни видимости включают Public, Protected и Private.
• Рабочий процесс – Набор действий, приводящих к определенному результату.

Популярные книги по UML

Вот некоторые из самых продаваемых книг по UML, которые вы можете прочитать, чтобы изучить UML:

1. UML Distilled: Краткое руководство по стандартному языку объектного моделирования
2. UML 2 и унифицированный процесс: Практический анализ и проектирование на основе объектно-ориентированного подхода
3. Изучение UML 2.0
4. Разработка веб-приложений с использованием UML
5. Справочник по унифицированному языку моделирования
6. Элементы стиля UML™ 2.0
7. UML для программистов на Java
8. Схема UML
9. Руководство пользователя по унифицированному языку моделирования
10. Руководство по сертификации UML 2: Экзамены на базовом и среднем уровне
11. Основы объектно-ориентального проектирования в UML
12. Применение моделирования объектов, управляемого сценариями использования, с помощью UML: Пример электронной коммерции с комментариями
13. Проектирование гибких объектно-ориентированных систем с помощью UML
14. Моделирование объектов, управляемое сценариями использования, с помощью UML
15. Анализ и проектирование систем с использованием UML версии 2.0: Объектно-ориентированный подход
16. UML 2.0 в двух словах
17. Объектно-ориентированный анализ и проектирование с применением
18. Объяснение UML
19. Паттерны проектирования: Элементы повторно используемого объектно-ориентированного программного обеспечения
20. Основы объектов: Гибкое модельно-ориентированное разработка с использованием UML 2.0

Связанные ссылки

1. Профессиональный инструмент проектирования UML для визуального моделирования