UML — Обзор

UML — это стандартный язык для определения, визуализации, конструирования и документирования артефактов программных систем.

UML был создан Группой управления объектами (OMG), а проект спецификации UML 1.0 был предложен OMG в январе 1997 года.

OMG постоянно прилагает усилия для создания действительно отраслевого стандарта.

• UML расшифровывается как унифицированный язык моделирования .

• UML отличается от других распространенных языков программирования, таких как C ++, Java, COBOL и т. Д.

• UML — это графический язык, используемый для создания программных чертежей.

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

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

UML расшифровывается как унифицированный язык моделирования .

UML отличается от других распространенных языков программирования, таких как C ++, Java, COBOL и т. Д.

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

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

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

UML не является языком программирования, но инструменты могут использоваться для генерации кода на разных языках с использованием диаграмм UML. UML имеет прямое отношение к объектно-ориентированному анализу и дизайну. После некоторой стандартизации UML стал стандартом OMG.

Цели UML

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

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

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

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

Концептуальная модель UML

Чтобы понять концептуальную модель UML, сначала нам нужно уточнить, что такое концептуальная модель? и зачем нужна концептуальная модель?

• Концептуальная модель может быть определена как модель, которая состоит из концепций и их отношений.

• Концептуальная модель — это первый шаг перед построением диаграммы UML. Это помогает понять сущности в реальном мире и то, как они взаимодействуют друг с другом.

Концептуальная модель может быть определена как модель, которая состоит из концепций и их отношений.

Концептуальная модель — это первый шаг перед построением диаграммы UML. Это помогает понять сущности в реальном мире и то, как они взаимодействуют друг с другом.

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

• UML строительные блоки
• Правила подключения строительных блоков
• Общие механизмы UML

Объектно-ориентированные концепции

UML может быть описан как преемник объектно-ориентированного (ОО) анализа и проектирования.

Объект содержит как данные, так и методы, управляющие данными. Данные представляют состояние объекта. Класс описывает объект, и они также формируют иерархию для моделирования реальной системы. Иерархия представлена ​​как наследование, и классы также могут быть связаны по-разному в соответствии с требованием.

Объекты — это сущности реального мира, которые существуют вокруг нас, и основные понятия, такие как абстракция, инкапсуляция, наследование и полиморфизм, могут быть представлены с использованием UML.

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

Ниже приведены некоторые фундаментальные концепции объектно-ориентированного мира —

• Объекты — объекты представляют собой сущность и основной строительный блок.

• Класс — Класс — это синяя печать объекта.

• Абстракция — Абстракция представляет поведение объекта реального мира.

• Инкапсуляция. Инкапсуляция — это механизм связывания данных друг с другом и сокрытия их от внешнего мира.

• Наследование — Наследование — это механизм создания новых классов из существующих.

• Полиморфизм — определяет механизм существования в разных формах.

Объекты — объекты представляют собой сущность и основной строительный блок.

Класс — Класс — это синяя печать объекта.

Абстракция — Абстракция представляет поведение объекта реального мира.

Инкапсуляция. Инкапсуляция — это механизм связывания данных друг с другом и сокрытия их от внешнего мира.

Наследование — Наследование — это механизм создания новых классов из существующих.

Полиморфизм — определяет механизм существования в разных формах.

ОО Анализ и дизайн

ОО можно определить как расследование, а если быть более конкретным, это исследование объектов. Проектирование означает сотрудничество идентифицированных объектов.

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

Цель ОО анализа и проектирования может быть описана как —

• Идентификация объектов системы.

• Выявление их отношений.

• Создание дизайна, который можно преобразовать в исполняемые файлы с использованием ОО-языков.

Идентификация объектов системы.

Выявление их отношений.

Создание дизайна, который можно преобразовать в исполняемые файлы с использованием ОО-языков.

Есть три основных шага, где концепции ОО применяются и реализуются. Шаги могут быть определены как

OO Analysis → OO Design → OO implementation using OO languages

Вышеупомянутые три пункта могут быть подробно описаны как —

• Во время ОО-анализа наиболее важной целью является идентификация объектов и их правильное описание. Если эти объекты идентифицированы эффективно, то следующая задача дизайна будет легкой. Объекты должны быть идентифицированы с обязанностями. Обязанности — это функции, выполняемые объектом. У каждого объекта есть некоторый тип обязанностей, которые нужно выполнить. Когда эти обязанности согласованы, цель системы выполняется.

• Второй этап — ОО дизайн. На этом этапе акцент делается на требования и их выполнение. На этом этапе объекты взаимодействуют в соответствии с их предполагаемой ассоциацией. После завершения ассоциации проектирование также завершено.

• Третий этап — реализация ОО. На этом этапе проектирование осуществляется с использованием ОО-языков, таких как Java, C ++ и т. Д.

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

Второй этап — ОО дизайн. На этом этапе акцент делается на требования и их выполнение. На этом этапе объекты взаимодействуют в соответствии с их предполагаемой ассоциацией. После завершения ассоциации проектирование также завершено.

Третий этап — реализация ОО. На этом этапе проектирование осуществляется с использованием ОО-языков, таких как Java, C ++ и т. Д.

Роль UML в ОО Дизайн

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

Если мы посмотрим на диаграмму классов, диаграмму объектов, диаграмму сотрудничества, диаграммы взаимодействия, то все они будут в основном разработаны на основе объектов.

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

UML — Строительные блоки

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

• UML строительные блоки
• Правила подключения строительных блоков
• Общие механизмы UML

В этой главе описываются все строительные блоки UML. Строительные блоки UML могут быть определены как —

• вещи
• Отношения
• Диаграммы

вещи

Вещи являются наиболее важными строительными блоками UML. Вещи могут быть —

• структурная
• поведенческий
• группирование
• Annotational

Структурные Вещи

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

Класс — класс представляет собой набор объектов, имеющих схожие обязанности.

Интерфейс — Интерфейс определяет набор операций, которые определяют ответственность класса.

Сотрудничество — Сотрудничество определяет взаимодействие между элементами.

Вариант использования. Вариант использования представляет собой набор действий, выполняемых системой для конкретной цели.

Компонент — Компонент описывает физическую часть системы.

Узел — узел может быть определен как физический элемент, который существует во время выполнения.

Поведенческие вещи

Поведенческая вещь состоит из динамических частей моделей UML. Ниже приведены поведенческие вещи —

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

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

Группировка вещей

Группирование может быть определено как механизм для группировки элементов модели UML вместе. Доступна только одна группировка —

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

Аннотационные вещи

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

отношения

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

Есть четыре вида доступных отношений.

зависимость

Зависимость — это отношения между двумя вещами, в которых изменение одного элемента также влияет на другой.

ассоциация

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

Обобщение

Обобщение может быть определено как отношение, которое связывает специализированный элемент с обобщенным элементом. Это в основном описывает отношения наследования в мире объектов.

реализация

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

UML-диаграммы

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

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

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

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

UML — Архитектура

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

UML играет важную роль в определении различных перспектив системы. Эти перспективы —

• дизайн
• Реализация
• Процесс
• развертывание

Центр — это вид Use Case, который соединяет все эти четыре. Вариант использования представляет функциональность системы. Следовательно, другие перспективы связаны с вариантом использования.

Проектирование системы состоит из классов, интерфейсов и совместной работы. UML предоставляет диаграмму классов, диаграмму объектов для поддержки этого.

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

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

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

UML — Типы моделирования

Очень важно различать модель UML. Для разных типов UML-моделирования используются разные диаграммы. Существует три важных типа UML-моделирования.

Структурное моделирование

Структурное моделирование фиксирует статические особенности системы. Они состоят из следующего —

• Диаграммы классов
• Диаграммы объектов
• Диаграммы развертывания
• Пакетные диаграммы
• Составная структурная схема
• Диаграмма компонентов

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

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

Поведенческое моделирование

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

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

Все вышеперечисленное показывает динамическую последовательность потоков в системе.

Архитектурное моделирование

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

UML — Основные нотации

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

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

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

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

Структурные Вещи

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

• Классы
• объект
• Интерфейс
• сотрудничество
• Случай использования
• Активные занятия
• Компоненты
• Вершины

Запись класса

Класс UML представлен на следующем рисунке. Диаграмма разделена на четыре части.

• Верхний раздел используется для названия класса.
• Второй используется для отображения атрибутов класса.
• Третий раздел используется для описания операций, выполняемых классом.
• Четвертый раздел является необязательным, чтобы показать любые дополнительные компоненты.

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

Обозначение объекта

Объект представлен так же, как и класс. Единственное отличие — это имя, которое подчеркнуто, как показано на следующем рисунке.

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

Нотация интерфейса

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

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

Совместная запись

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

Сотрудничество представляет собой ответственность. Как правило, обязанности в группе.

Обозначение варианта использования

Вариант использования представлен в виде затмения с именем внутри. Это может содержать дополнительные обязанности.

Вариант использования используется для захвата функциональных возможностей высокого уровня системы.

Обозначение актера

Актер может быть определен как некоторая внутренняя или внешняя сущность, которая взаимодействует с системой.

Актер используется в диаграмме прецедентов для описания внутренних или внешних объектов.

Нотация начального состояния

Начальное состояние определяется, чтобы показать начало процесса. Эта запись используется почти на всех диаграммах.

Нотация начального состояния используется для отображения начальной точки процесса.

Конечная государственная запись

Конечное состояние используется, чтобы показать конец процесса. Эта запись также используется почти на всех диаграммах для описания конца.

Использование нотации конечного состояния позволяет показать точку завершения процесса.

Нотация активного класса

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

Активный класс используется для представления параллелизма в системе.

Обозначение компонентов

Компонент в UML показан на следующем рисунке с именем внутри. Дополнительные элементы могут быть добавлены везде, где это необходимо.

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

Обозначение узла

Узел в UML представлен квадратной рамкой, как показано на следующем рисунке с именем. Узел представляет физический компонент системы.

Узел используется для представления физической части системы, такой как сервер, сеть и т. Д.

Поведенческие вещи

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

Взаимодействия могут быть двух типов —

• Последовательный (представлен диаграммой последовательности)
• Совместное (Представлено диаграммой сотрудничества)

Нотация взаимодействия

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

Взаимодействие используется для представления связи между компонентами системы.

Обозначение конечного автомата

Конечный автомат описывает различные состояния компонента в его жизненном цикле. Обозначения описаны на следующей диаграмме.

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

Группировка вещей

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

Обозначение пакета

Обозначение пакета показано на следующем рисунке и используется для переноса компонентов системы.

Аннотационные вещи

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

Примечание Примечание

Это обозначение показано на следующем рисунке. Эти обозначения используются для предоставления необходимой информации о системе.

Отношения

Модель не является полной, если отношения между элементами не описаны должным образом. Отношение придает правильное значение модели UML. Ниже приведены различные типы отношений, доступные в UML.

• зависимость
• ассоциация
• Обобщение
• растяжимость

Обозначение зависимостей

Зависимость является важным аспектом в элементах UML. Он описывает зависимые элементы и направление зависимости.

Зависимость представлена ​​пунктирной стрелкой, как показано на следующем рисунке. Стрелка представляет независимый элемент, а другой конец представляет зависимый элемент.

Зависимость используется для представления зависимости между двумя элементами системы

Обозначение ассоциации

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

Ассоциация представлена ​​пунктирной линией со стрелками (без) с обеих сторон. Два конца представляют два связанных элемента, как показано на следующем рисунке. Кратность также упоминается на концах (1, * и т. Д.), Чтобы показать, сколько объектов связано.

Ассоциация используется для представления отношений между двумя элементами системы.

Обобщающая запись

Обобщение описывает наследование отношений объектно-ориентированного мира. Это родительские и дочерние отношения.

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

Обобщение используется для описания родительско-дочерних отношений двух элементов системы.

Нотация расширяемости

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

• Стереотипы (Представляет новые элементы)
• Помеченные значения (Представляет новые атрибуты)
• Ограничения (Представляет границы)

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

UML — Стандартные диаграммы

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

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

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

Мы готовим UML-диаграммы, чтобы лучше и проще понять систему. Одной диаграммы недостаточно, чтобы охватить все аспекты системы. UML определяет различные виды диаграмм, чтобы охватить большинство аспектов системы.

Вы также можете создать свой собственный набор диаграмм в соответствии с вашими требованиями. Диаграммы, как правило, создаются в пошаговом и итеративном порядке.

Есть две широкие категории диаграмм, и они снова делятся на подкатегории —

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

• Поведенческие Диаграммы

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

Поведенческие Диаграммы

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

Структурные диаграммы представляют статический аспект системы. Эти статические аспекты представляют те части диаграммы, которые образуют основную структуру и поэтому являются стабильными.

Эти статические части представлены классами, интерфейсами, объектами, компонентами и узлами. Четыре структурные схемы —

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

Диаграмма классов

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

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

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

Диаграмма объектов

Диаграммы объектов могут быть описаны как экземпляры диаграмм классов. Таким образом, эти диаграммы более близки к реальным сценариям, где мы внедряем систему.

Диаграммы объектов — это набор объектов, и их взаимосвязи аналогичны диаграммам классов. Они также представляют статическое представление системы.

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

Диаграмма компонентов

Диаграммы компонентов представляют собой набор компонентов и их взаимосвязей. Эти компоненты состоят из классов, интерфейсов или совместной работы. Диаграммы компонентов представляют собой представление реализации системы.

На этапе проектирования программные артефакты (классы, интерфейсы и т. Д.) Системы располагаются в разных группах в зависимости от их взаимосвязи. Теперь эти группы известны как компоненты.

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

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

Диаграммы развертывания представляют собой набор узлов и их взаимосвязей. Эти узлы являются физическими объектами, на которых развернуты компоненты.

Диаграммы развертывания используются для визуализации представления развертывания системы. Обычно это используется командой развертывания.

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

Поведенческие Диаграммы

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

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

UML имеет следующие пять типов поведенческих диаграмм —

• Диаграмма вариантов использования
• Схема последовательности
• Диаграмма сотрудничества
• Диаграмма состояний
• Диаграмма деятельности

Диаграмма вариантов использования

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

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

Схема последовательности

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

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

Диаграмма сотрудничества

Диаграмма сотрудничества — это еще одна форма диаграммы взаимодействия. Он представляет собой структурную организацию системы и отправленные / полученные сообщения. Структурная организация состоит из объектов и связей.

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

Диаграмма состояний

Предполагается, что любая система реального времени будет реагировать на какие-то внутренние / внешние события. Эти события отвечают за изменение состояния системы.

Диаграмма диаграммы состояний используется для представления изменения состояния системы, управляемого событиями. Он в основном описывает изменение состояния класса, интерфейса и т. Д.

Диаграмма состояния диаграммы используется для визуализации реакции системы на внутренние / внешние факторы.

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

Диаграмма действий описывает поток управления в системе. Он состоит из действий и ссылок. Поток может быть последовательным, параллельным или разветвленным.

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

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

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

UML — Диаграмма классов

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

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

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

Назначение диаграмм классов

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

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

Назначение диаграммы классов можно обобщить как —

• Анализ и проектирование статического представления приложения.

• Опишите обязанности системы.

• База для диаграмм компонентов и развертывания.

• Прямая и обратная инженерия.

Анализ и проектирование статического представления приложения.

Опишите обязанности системы.

База для диаграмм компонентов и развертывания.

Прямая и обратная инженерия.

Как нарисовать диаграмму классов?

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

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

Диаграмма классов в основном представляет собой графическое представление статического представления системы и представляет различные аспекты приложения. Коллекция диаграмм классов представляет всю систему.

Следующие пункты следует помнить при рисовании диаграммы классов —

• Название диаграммы классов должно иметь смысл для описания аспекта системы.

• Каждый элемент и их отношения должны быть определены заранее.

• Ответственность (атрибуты и методы) каждого класса должны быть четко определены

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

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

• Наконец, перед тем, как сделать окончательный вариант, диаграмма должна быть нарисована на обычной бумаге и переработана как можно больше раз, чтобы сделать ее правильной.

Название диаграммы классов должно иметь смысл для описания аспекта системы.

Каждый элемент и их отношения должны быть определены заранее.

Ответственность (атрибуты и методы) каждого класса должны быть четко определены

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

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

Наконец, перед тем, как сделать окончательный вариант, диаграмма должна быть нарисована на обычной бумаге и переработана как можно больше раз, чтобы сделать ее правильной.

Следующая диаграмма является примером системы заказов приложения. Он описывает конкретный аспект всего приложения.

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

• Класс Order является абстрактным классом и имеет два конкретных класса (отношения наследования) SpecialOrder и NormalOrder.

• Два унаследованных класса имеют все свойства как класс Order. Кроме того, они имеют дополнительные функции, такие как dispatch () и receive ().

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

Класс Order является абстрактным классом и имеет два конкретных класса (отношения наследования) SpecialOrder и NormalOrder.

Два унаследованных класса имеют все свойства как класс Order. Кроме того, они имеют дополнительные функции, такие как dispatch () и receive ().

Следующая диаграмма классов была составлена ​​с учетом всех точек, упомянутых выше.

Где использовать диаграммы классов?

Диаграмма классов является статической диаграммой и используется для моделирования статического представления системы. Статическое представление описывает словарь системы.

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

Как правило, UML-диаграммы напрямую не сопоставляются с какими-либо объектно-ориентированными языками программирования, но диаграмма классов является исключением.

Диаграмма классов четко показывает сопоставление с объектно-ориентированными языками, такими как Java, C ++ и т. Д. Из практического опыта диаграмма классов обычно используется для целей построения.

В двух словах можно сказать, что диаграммы классов используются для —

• Описание статического вида системы.

• Показ сотрудничества между элементами статического представления.

• Описание функциональных возможностей, выполняемых системой.

• Построение программных приложений с использованием объектно-ориентированных языков.

Описание статического вида системы.

Показ сотрудничества между элементами статического представления.

Описание функциональных возможностей, выполняемых системой.

Построение программных приложений с использованием объектно-ориентированных языков.

UML — Диаграммы объектов

Диаграммы объектов являются производными от диаграмм классов, поэтому диаграммы объектов зависят от диаграмм классов.

Диаграммы объектов представляют собой экземпляр диаграммы классов. Основные понятия одинаковы для диаграмм классов и диаграмм объектов. Диаграммы объектов также представляют статическое представление системы, но это статическое представление представляет собой снимок системы в определенный момент.

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

Назначение объектных диаграмм

Цель диаграммы должна быть четко понята для ее практической реализации. Цели объектных диаграмм аналогичны диаграммам классов.

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

Это означает, что диаграмма объекта ближе к реальному поведению системы. Цель состоит в том, чтобы захватить статическое представление системы в определенный момент.

Назначение диаграммы объекта можно обобщить как —

• Прямая и обратная инженерия.

• Объектные отношения системы

• Статический вид взаимодействия.

• Понять поведение объектов и их взаимосвязь с практической точки зрения.

Прямая и обратная инженерия.

Объектные отношения системы

Статический вид взаимодействия.

Понять поведение объектов и их взаимосвязь с практической точки зрения.

Как нарисовать диаграмму объекта?

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

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

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

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

• Сначала проанализируйте систему и решите, какие экземпляры имеют важные данные и связь.

• Во-вторых, рассмотрим только те экземпляры, которые будут охватывать функциональность.

• В-третьих, проведите некоторую оптимизацию, поскольку количество экземпляров не ограничено.

Сначала проанализируйте систему и решите, какие экземпляры имеют важные данные и связь.

Во-вторых, рассмотрим только те экземпляры, которые будут охватывать функциональность.

В-третьих, проведите некоторую оптимизацию, поскольку количество экземпляров не ограничено.

Перед тем, как нарисовать диаграмму объекта, необходимо запомнить и понять следующие вещи:

• Диаграммы объектов состоят из объектов.

• Ссылка на объектной диаграмме используется для соединения объектов.

• Объекты и ссылки — это два элемента, используемые для построения диаграммы объекта.

Диаграммы объектов состоят из объектов.

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

Объекты и ссылки — это два элемента, используемые для построения диаграммы объекта.

После этого перед началом построения диаграммы необходимо решить следующие вопросы:

• Диаграмма объекта должна иметь осмысленное имя для обозначения ее цели.

• Наиболее важные элементы должны быть определены.

• Связь между объектами должна быть уточнена.

• Значения различных элементов должны быть зафиксированы для включения в диаграмму объекта.

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

Диаграмма объекта должна иметь осмысленное имя для обозначения ее цели.

Наиболее важные элементы должны быть определены.

Связь между объектами должна быть уточнена.

Значения различных элементов должны быть зафиксированы для включения в диаграмму объекта.

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

Следующая диаграмма является примером диаграммы объекта. Он представляет собой систему управления заказами, которую мы обсудили в главе «Диаграмма классов». Следующая диаграмма представляет собой экземпляр системы в конкретный момент покупки. Он имеет следующие объекты.

• Покупатель

• порядок

• Особое распоряжение

• NormalOrder

Покупатель

порядок

Особое распоряжение

NormalOrder

Теперь объект клиента (C) связан с тремя объектами заказа (O1, O2 и O3). Эти объекты порядка связаны с объектами особого порядка и нормального порядка (S1, S2 и N1). У покупателя есть три следующих заказа с разными номерами (12, 32 и 40) на определенное время.

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

Для заказов значения 12, 32 и 40, что означает, что объекты имеют эти значения для определенного момента (здесь конкретное время, когда совершается покупка, рассматривается как момент), когда экземпляр захвачен

То же самое верно для объектов специального заказа и обычного заказа, у которых количество заказов равно 20, 30 и 60. Если рассматривается другое время покупки, то эти значения будут соответственно изменены.

Следующая диаграмма объекта была составлена ​​с учетом всех точек, упомянутых выше

Где использовать объектные диаграммы?

Диаграммы объектов можно представить как снимок работающей системы в определенный момент. Давайте рассмотрим пример бегущего поезда

Теперь, если вы сделаете снимок бегущего поезда, вы увидите статичное изображение, на котором есть следующее:

• Определенное состояние, которое работает.

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

Определенное состояние, которое работает.

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

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

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

• Создание прототипа системы.

• Обратный инжиниринг.

• Моделирование сложных структур данных.

• Понимание системы с практической точки зрения.

Создание прототипа системы.

Обратный инжиниринг.

Моделирование сложных структур данных.

Понимание системы с практической точки зрения.

UML — Диаграммы компонентов

Диаграммы компонентов различны с точки зрения природы и поведения. Диаграммы компонентов используются для моделирования физических аспектов системы. Теперь вопрос в том, каковы эти физические аспекты? Физические аспекты — это такие элементы, как исполняемые файлы, библиотеки, файлы, документы и т. Д., Которые находятся в узле.

Диаграммы компонентов используются для визуализации организации и связей между компонентами в системе. Эти диаграммы также используются для создания исполняемых систем.

Назначение диаграмм компонентов

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

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

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

Диаграмма одного компонента не может представлять всю систему, но для представления целого используется набор диаграмм.

Назначение диаграммы компонентов можно суммировать как:

• Визуализируйте компоненты системы.

• Создайте исполняемые файлы, используя прямой и обратный инжиниринг.

• Опишите организацию и отношения компонентов.

Визуализируйте компоненты системы.

Создайте исполняемые файлы, используя прямой и обратный инжиниринг.

Опишите организацию и отношения компонентов.

Как нарисовать диаграмму компонентов?

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

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

Первоначально система спроектирована с использованием различных UML-диаграмм, а затем, когда артефакты готовы, для получения представления о реализации используются диаграммы компонентов.

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

Перед составлением диаграммы компонентов необходимо четко определить следующие артефакты:

• Файлы, используемые в системе.

• Библиотеки и другие артефакты, имеющие отношение к приложению.

• Отношения между артефактами.

Файлы, используемые в системе.

Библиотеки и другие артефакты, имеющие отношение к приложению.

Отношения между артефактами.

После выявления артефактов необходимо учитывать следующие моменты.

• Используйте значимое имя, чтобы определить компонент, для которого должна быть построена диаграмма.

• Подготовьте мысленный план, прежде чем использовать инструменты.

• Используйте заметки для уточнения важных моментов.

Используйте значимое имя, чтобы определить компонент, для которого должна быть построена диаграмма.

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

Используйте заметки для уточнения важных моментов.

Ниже приведена схема компонентов системы управления заказами. Здесь артефакты являются файлами. На диаграмме показаны файлы в приложении и их отношения. На самом деле, диаграмма компонентов также содержит библиотеки, библиотеки, папки и т. Д.

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

Следующая диаграмма компонентов была составлена ​​с учетом всех пунктов, упомянутых выше.

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

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

Эти диаграммы показывают физические компоненты системы. Чтобы прояснить это, мы можем сказать, что диаграммы компонентов описывают организацию компонентов в системе.

Организация может быть далее описана как расположение компонентов в системе. Эти компоненты организованы специальным образом для удовлетворения системных требований.

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

Диаграммы компонентов очень важны с точки зрения реализации. Таким образом, команда реализации приложения должна иметь правильное знание деталей компонента

Диаграммы компонентов могут быть использованы для —

• Смоделируйте компоненты системы.

• Смоделируйте схему базы данных.

• Моделируйте исполняемые файлы приложения.

• Смоделируйте исходный код системы.

Смоделируйте компоненты системы.

Смоделируйте схему базы данных.

Моделируйте исполняемые файлы приложения.

Смоделируйте исходный код системы.

UML — Диаграммы развертывания

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

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

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

Сам термин «Развертывание» описывает назначение диаграммы. Диаграммы развертывания используются для описания компонентов оборудования, в которых развернуты компоненты программного обеспечения. Диаграммы компонентов и схемы развертывания тесно связаны.

Диаграммы компонентов используются для описания компонентов, а диаграммы развертывания показывают, как они развернуты на оборудовании.

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

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

Назначение диаграмм развертывания можно описать как —

• Визуализируйте аппаратную топологию системы.

• Опишите аппаратные компоненты, используемые для развертывания программных компонентов.

• Опишите узлы обработки во время выполнения.

Визуализируйте аппаратную топологию системы.

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

Опишите узлы обработки во время выполнения.

Как нарисовать схему развертывания?

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

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

• Спектакль

• Масштабируемость

• Ремонтопригодность

• портативность

Спектакль

Масштабируемость

Ремонтопригодность

портативность

Перед составлением схемы развертывания необходимо определить следующие артефакты:

• Вершины

• Отношения между узлами

Вершины

Отношения между узлами

Ниже приведен пример схемы развертывания для представления представления о развертывании системы управления заказами. Здесь мы показали узлы как —

• монитор

• Модем

• Кеширующий сервер

• сервер

монитор

Модем

Кеширующий сервер

сервер

Предполагается, что это веб-приложение, которое развертывается в кластерной среде с использованием сервера 1, сервера 2 и сервера 3. Пользователь подключается к приложению через Интернет. Управление передается от сервера кэширования в кластерную среду.

Следующая схема развертывания была составлена ​​с учетом всех пунктов, упомянутых выше.

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

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

Диаграммы развертывания можно представить как аппаратные компоненты / узлы, на которых находятся программные компоненты.

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

Для удовлетворения этих требований необходимо, чтобы аппаратные компоненты были спроектированы эффективно и рентабельно.

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

Диаграммы развертывания могут быть использованы —

• Для моделирования аппаратной топологии системы.

• Для моделирования встроенной системы.

• Для моделирования аппаратных деталей для системы клиент / сервер.

• Для моделирования аппаратных деталей распределенного приложения.

• Для прямого и обратного проектирования.

Для моделирования аппаратной топологии системы.

Для моделирования встроенной системы.

Для моделирования аппаратных деталей для системы клиент / сервер.

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

Для прямого и обратного проектирования.

UML — Диаграммы вариантов использования

Для моделирования системы наиболее важным аспектом является захват динамического поведения. Динамическое поведение означает поведение системы, когда она работает / работает.

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

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

Следовательно, для моделирования всей системы используется ряд диаграмм вариантов использования.

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

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

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

Когда начальная задача завершена, диаграммы вариантов использования моделируются для представления внешнего вида.

Вкратце, цели диаграмм вариантов использования можно сказать следующим образом:

• Используется для сбора требований системы.

• Используется для получения внешнего вида системы.

• Определите внешние и внутренние факторы, влияющие на систему.

• Покажите взаимодействие между требованиями актеров.

Используется для сбора требований системы.

Используется для получения внешнего вида системы.

Определите внешние и внутренние факторы, влияющие на систему.

Покажите взаимодействие между требованиями актеров.

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

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

Можно сказать, что варианты использования — это не что иное, как системные функции, написанные организованным образом. Второе, что имеет отношение к сценариям использования, — это актеры. Актеры могут быть определены как то, что взаимодействует с системой.

Актерами могут быть пользователи, некоторые внутренние приложения или некоторые внешние приложения. Когда мы планируем нарисовать диаграмму варианта использования, у нас должны быть определены следующие элементы.

• Функциональные возможности должны быть представлены как вариант использования

• Актеры

• Отношения между вариантами использования и актерами.

Функциональные возможности должны быть представлены как вариант использования

Актеры

Отношения между вариантами использования и актерами.

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

• Название варианта использования очень важно. Имя должно быть выбрано таким образом, чтобы оно могло идентифицировать выполняемые функции.

• Дайте подходящее имя для актеров.

• Четко покажите отношения и зависимости на диаграмме.

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

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

Название варианта использования очень важно. Имя должно быть выбрано таким образом, чтобы оно могло идентифицировать выполняемые функции.

Дайте подходящее имя для актеров.

Четко покажите отношения и зависимости на диаграмме.

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

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

Ниже приведен пример схемы использования, представляющей систему управления заказами. Следовательно, если мы посмотрим на диаграмму, то найдем три варианта использования (Order, SpecialOrder и NormalOrder) и один субъект, который является клиентом.

Варианты использования SpecialOrder и NormalOrder расширены от варианта использования Order . Следовательно, они имеют расширенные отношения. Еще одним важным моментом является определение границы системы, которая показана на рисунке. Клиент-участник находится вне системы, поскольку он является внешним пользователем системы.

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

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

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

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

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

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

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

Диаграммы прецедентов могут быть использованы для —

• Анализ требований и дизайн высокого уровня.

• Смоделируйте контекст системы.

• Обратный инжиниринг.

• Форвард инжиниринг.

Анализ требований и дизайн высокого уровня.

Смоделируйте контекст системы.

Обратный инжиниринг.

Форвард инжиниринг.

UML — Диаграммы взаимодействия

Из термина «Взаимодействие» ясно, что диаграмма используется для описания некоторого типа взаимодействий между различными элементами в модели. Это взаимодействие является частью динамического поведения системы.

Это интерактивное поведение представлено в UML двумя диаграммами, известными как диаграмма последовательности и диаграмма сотрудничества . Основное назначение обеих диаграмм схожи.

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

Назначение диаграмм взаимодействия

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

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

Целью диаграммы взаимодействия является —

• Чтобы зафиксировать динамическое поведение системы.

• Для описания потока сообщений в системе.

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

• Для описания взаимодействия между объектами.

Чтобы зафиксировать динамическое поведение системы.

Для описания потока сообщений в системе.

Для описания структурной организации объектов.

Для описания взаимодействия между объектами.

Как нарисовать диаграмму взаимодействия?

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

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

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

• Объекты, принимающие участие во взаимодействии.

• Потоки сообщений среди объектов.

• Последовательность, в которой сообщения передаются.

• Организация объекта.

Объекты, принимающие участие во взаимодействии.

Потоки сообщений среди объектов.

Последовательность, в которой сообщения передаются.

Организация объекта.

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

Диаграмма последовательности

Диаграмма последовательности имеет четыре объекта (Customer, Order, SpecialOrder и NormalOrder).

На следующем рисунке показана последовательность сообщений для объекта SpecialOrder, и то же самое можно использовать в случае объекта NormalOrder . Важно понимать временную последовательность потоков сообщений. Поток сообщений — это не что иное, как вызов метода объекта.

Первый вызов — sendOrder (), который является методом объекта Order . Следующий вызов — метод verify (), который является методом объекта SpecialOrder, а последний вызов — Dispatch (), который является методом объекта SpecialOrder . Следующая диаграмма в основном описывает вызовы методов от одного объекта к другому, и это также фактический сценарий, когда система работает.

Диаграмма сотрудничества

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

Вызовы методов аналогичны вызовам диаграмм последовательности. Однако различие в том, что диаграмма последовательности не описывает организацию объекта, тогда как диаграмма сотрудничества показывает организацию объекта.

Чтобы выбрать между этими двумя диаграммами, акцент делается на тип требования. Если временная последовательность важна, тогда используется диаграмма последовательности. Если требуется организация, используется диаграмма сотрудничества.

Где использовать диаграммы взаимодействия?

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

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

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

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

Диаграммы взаимодействия могут быть использованы —

• Для моделирования потока управления по временной последовательности.

• Моделировать поток управления структурными организациями.

• Для форвард инжиниринга.

• Для реверс-инжиниринга.

Для моделирования потока управления по временной последовательности.

Моделировать поток управления структурными организациями.

Для форвард инжиниринга.

Для реверс-инжиниринга.

UML — диаграммы состояний

Название самой диаграммы поясняет назначение диаграммы и другие детали. Он описывает различные состояния компонента в системе. Состояния специфичны для компонента / объекта системы.

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

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

Назначение диаграмм состояний

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

Диаграмма диаграммы состояний описывает поток управления из одного состояния в другое. Состояния определяются как состояние, при котором объект существует, и он изменяется при запуске какого-либо события. Наиболее важной целью диаграммы состояний является моделирование времени жизни объекта от создания до завершения.

Диаграммы диаграммы состояний также используются для прямого и обратного проектирования системы. Однако основной целью является моделирование реактивной системы.

Ниже приведены основные цели использования диаграмм Statechart —

• Для моделирования динамического аспекта системы.

• Для моделирования времени жизни реактивной системы.

• Для описания различных состояний объекта в течение его жизни.

• Определите конечный автомат для моделирования состояний объекта.

Для моделирования динамического аспекта системы.

Для моделирования времени жизни реактивной системы.

Для описания различных состояний объекта в течение его жизни.

Определите конечный автомат для моделирования состояний объекта.

Как нарисовать диаграмму Statechart?

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

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

Прежде чем рисовать диаграмму Statechart, мы должны уточнить следующие моменты —

• Определите важные объекты для анализа.

• Определите штаты.

• Определите события.

Определите важные объекты для анализа.

Определите штаты.

Определите события.

Ниже приведен пример диаграммы состояний, где анализируется состояние объекта заказа.

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

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

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

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

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

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

Если мы посмотрим на практическую реализацию диаграммы состояний, то она в основном используется для анализа состояний объектов, на которые влияют события. Этот анализ полезен для понимания поведения системы во время ее выполнения.

Основное использование может быть описано как —

• Для моделирования состояния объекта системы.

• Для моделирования реактивной системы. Реактивная система состоит из реактивных объектов.

• Выявить события, ответственные за изменения состояния.

• Прямая и обратная инженерия.

Для моделирования состояния объекта системы.

Для моделирования реактивной системы. Реактивная система состоит из реактивных объектов.

Выявить события, ответственные за изменения состояния.

Прямая и обратная инженерия.

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

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

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

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

Назначение диаграмм деятельности

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

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

Он не показывает поток сообщений от одного действия к другому. Диаграмма деятельности иногда рассматривается как блок-схема. Хотя диаграммы выглядят как блок-схема, это не так. Он показывает разные потоки, такие как параллельный, разветвленный, параллельный и одиночный.

Цель диаграммы деятельности может быть описана как —

• Нарисуйте поток активности системы.

• Опишите последовательность от одного занятия к другому.

• Опишите параллельное, разветвленное и параллельное течение системы.

Нарисуйте поток активности системы.

Опишите последовательность от одного занятия к другому.

Опишите параллельное, разветвленное и параллельное течение системы.

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

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

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

Прежде чем рисовать диаграмму деятельности, мы должны выделить следующие элементы:

• мероприятия

• ассоциация

• условия

• Ограничения

мероприятия

ассоциация

условия

Ограничения

После того, как вышеупомянутые параметры определены, нам необходимо составить мысленный план всего потока. Этот ментальный план затем преобразуется в диаграмму деятельности.

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

Следующая диаграмма нарисована с четырьмя основными действиями —

• Отправить заказ клиентом

• Получение заказа

• Подтвердить заказ

• Отправить заказ

Отправить заказ клиентом

Получение заказа

Подтвердить заказ

Отправить заказ

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

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

Основное использование диаграммы активности аналогично другим четырем диаграммам UML. Конкретное использование заключается в моделировании потока управления от одного действия к другому. Этот поток управления не включает сообщения.

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

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

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

Диаграмма деятельности может быть использована для —

Моделирование рабочего процесса с использованием действий.

Моделирование бизнес-требований.

Высокий уровень понимания функциональных возможностей системы.

Исследование бизнес-требований на более позднем этапе.