Разновидностью какой диаграммы uml являются активностей. Основные диаграммы языка UML

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

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

10.4. ДИАГРАММЫ UML 10.4.1. Типы визуальных диаграмм UMLUML позволяет создавать несколько типов визуальных диаграмм: диаграммы вариантов использования; диаграммы последовательности; кооперативные диаграммы; диаграммы классов; диаграммы состояний; диаграммы

1.2.6. Каркас диаграммы На рис. 1.2.26 показан типичный пример диаграммы декомпозиции с граничными рамками, которые называются каркасом диаграммы. Рис. 1.2.26. Пример диаграммы декомпозиции с каркасомКаркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть).

Временные диаграммы Чтобы получить временные диаграммы входного и выходного напряжений, необходимо слегка изменить входной файл. Как и в предыдущем примере, будет использовано синусоидальное входное напряжение:Vi 1 0 sin (0 0. 5V 5kHz)Наряду с анализом переходных процессов

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

5.1.14. Диаграммы Диаграмм - графическое представление числовых данных таблицы. Pages предлагает несколько видов диаграмм: Column (Столбцовая), Stacked Column (Многоярусные столбцы), Ваг (Гистограмма), Stacked Ваг (Многоярусная гистограмма), Line (Линейная), Area (Площадь), Stacked Area (Многоярусная

5.2.8. Диаграммы Диаграмма - графическое представление данных из выбранного диапазона.Для построения диаграммы придерживайтесь следующего алгоритма1. Создать таблицу расчетных значений.2. Выделить нужный диапазон (он может состоять из не смежных прямоугольных

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

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

В заметке используется материалы из книжек: Иванов Д. Ю., Новиков Ф. А. Унифицированный язык моделирования UML и Леоненков. Самоучитель по UML .

Для начала определимся с редактором. Под Linux я перепробовал разные UML-редакторы, больше всего мне понравился UMLet , хоть он и написан на Java но шевелится весьма проворно и большинство заготовок сущностей в нем есть. Еще есть ArgoUML кроссплатформенный UML-редактор, написан тоже на Java, функционально-богат но подтормаживает больше.

Я остановился на UMLet , установим его под Arch Linux и Ubuntu :

# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

В UML все сущности можно разбить на такие типы:

• структурные;
• поведенческие;
• группирующие;
• аннотационные;

В UML используются четыре основных типа отношений:

Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой.

Ассоциация (association) - имеет место, если одна сущность непосредственно связана с другой (или с другими - ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности.

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

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

В UML 2 определено 13 типов диаграмм. По стандартам каждая диаграмма должна иметь рамку с прямоугольником (правый нижний угол скошенный) в левом верхнем углу, в котором указывается идентификатор диаграммы (тег) и название.

Диаграммы для изображения структуры системы :

• Диаграмма компонентов (component diagram, тег component );
• Диаграмма размещения (deployment diagram, тег deployment );
• Диаграмма классов (class diagram, тег class );
• Диаграмма объектов (object diagram, тег object );
• Диаграмма структуры внутренней (composite structure diagram, тег class );

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

• Диаграмма синхронизации (interaction diagram, тег timing );
• Диаграмма деятельности (activity diagram, тег activity );
• Диаграмма последовательности (sequence diagram, тег sd );
• Диаграмма коммуникации (communication diagram, тег comm );
• Диаграмма автомата (state machine diagram, тег state machine );
• Обзорная диаграмма взаимодействия (interaction overview diagram, тег interaction );

Особняком стоят диаграммы:

• Диаграмма использования(use case diagram, тег use case);
• Диаграмма пакетов (package diagram, тег package );

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

Диаграмма использования (use case diagram) - это наиболее общее представление функционального назначения системы.

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

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

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

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

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

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

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

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

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

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

Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому.

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

Диаграмма классов (class diagram) - основной способ описания статической структуры системы.

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

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

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

Над стрелкой могут находится специальные ключевые слова (стереотипы):

• "access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
• "bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
• "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
• "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
• "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

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

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

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

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

Диаграмма автомата

Диаграмма автомата (state machine diagram) или диаграмма состояний в UML 1 (state chart diagram) - это один из способов детального описания поведения в UML. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.

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

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

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

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

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

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

Диаграмма деятельности (activity diagram) - еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Используется для моделирования процесса выполнения операций.

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

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

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

Диаграмма последовательности (sequence diagram) - это способ описания поведения системы "на примерах".

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

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

Возможные виды сообщений (изображение взято у larin.in):

Диаграмма коммуникации

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

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

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

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

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

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс);

Диаграмма размещения

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

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

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

Диаграмма объектов (object diagram) - является экземпляром диаграммы классов.

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

Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.

Структурный классификатор изображается в виде прямоугольника, в верхней части которого находится имя классификатора. Внутри находятся части (parts). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port). Порты располагаются также на внешней границе структурного классификатора.

Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.

Диаграмма синхронизации

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

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

Диаграмма пакетов (package diagram) - единственное средство, позволяющее управлять сложностью самой модели.

Основные элементы нотации - пакеты и зависимости с различными стереотипами.

Модель сущность-связь (ER-модель)

Аналогом диаграммы классов (UML) может быть ER-модель , которая используется при проектировании баз-данных (реляционной модели).

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

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

Основные понятия:

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов, например, КЛИЕНТ 777 . Сущность фактически представляет из себя множество атрибутов.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Домен (domain) - множество значений (область определения) атрибута.

Существует три типа бинарных связей:

• один к одному - одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса, напимер, НАЧАЛЬНИК - ОТДЕЛ;
• 1 к N или один ко многим - одиночный экземпляр сущности одного класса связан со многими экземплярами сущности другого класса, например, ОТДЕЛ - СОТРУДНИК;
• N к M или многие ко многим - многие экземпляры сущности одного класса связаны со многими экземплярами сущности другого класса, например, СОТРУДНИК - ПРОЕКТ;
Словарь основных понятий по UML

Объект (object) - сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) - описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

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

Кооперация (collaboration) - совокупность объектов, которые взаимодействуют для достижения некоторой цели.

Действующее лицо (actor) - сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Компонент (component) - модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

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

Узел (node) - вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.

Состояние (state) - период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

Действие (action) - примитивное атомарное вычисление.

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

Классификатор (classifier) - это дескриптор множества однотипных объектов.

Дополнительное чтиво

• Фаулер М. UML. Основы, 3-е издание
• Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя

UML или Unified Modeling Language - язык графического описания для объектного моделирования в области разработки программного обеспечения. Но использование UML не ограничивается IT, другая большая сфера практического применения UML - моделирование бизнес-процессов, системного проектирования и отображения организационных структур. UML дает возможность разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий и сконцентрироваться на проектировании и разработке.

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

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

Типы диаграмм UML

В UML 14 типов диаграмм. Их можно разделить на 2 категории:

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

Иерархия типов диаграмм UML,
представленная диаграммой классов

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

1. Диаграмма классов является ключевым элементом в объектно-ориентированном моделировании. С помощью этой диаграммы (собственно, через классы , их атрибуты , методы и зависимости между классами) описывается модель предметной области и структура моделируемой системы.
2. Диаграмма компонентов отображает разбиение программного кода на крупные блоки (структурные компоненты) и показывает зависимости между ними. Компонентами могут быть пакеты, модули, библиотеки, файлы и т.д.
3. Объектная диаграмма показывает полный или частичный срез моделируемой системы в заданный момент времени. Она представляет экземплеры классов (объекты), их состояние (текущие значения аттрибутов) и отношения между ними.
4. Диаграмма композитной структуры демонстрирует внутреннюю структуру классов и, по возможности, взаимодействия между элементами этой структуры.
5. Диаграмма пакетов показывает пакеты и отношения между ними. Этот вид диаграмм служит для упрощения структуры модели (и, соответственно, работы с ней) через объединение элементов модели в группы по некоторым критериям.
6. Диаграмма развертывания моделирует развертывание программных компонентов (артефактов ) на вычислительных ресурсах/аппаратных компонентах (узлах ).
7. Диаграмма профилей описывает механизм расширения, позволяющий приспособить UML к разнообразным предметным областям и сферам деятельности.

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

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

1. Диаграмма деятельности показывает действия (actions ) из которых состоит некоторая деятельность (activity ). Диаграммы деятельности используются для моделирования бизнесс-процессов, технологических процессов, последовательных и параллельных вычислений.
2. Диаграмма вариантов использования (или диаграмма прецедентов ) описывает отношения между актёрами (действующими лицами) и вариантами использования моделируемой системы (ее возможностями). Основное назначение диаграммы - быть универсальным средством для заказчиков, разработчиков и конечных пользователей, с помощью которого можно было бы совместно обсуждать систему - ее возможности и поведение.
3. Диаграмма состояний изображает динамическое поведение сущности, показывая как эта сущность в зависимости от своего текущего состояния реагирует на различные события. По сути это диаграмма состояний из теории атоматов.
4. Диаграмма коммуникации (в ранних версиях диаграмма кооперации ) показывает взаимодействия между частями композитной структуры и ролями кооперации. На диаграмме явно указываются отношения между элементами (объектами).
5. Диаграмма последовательности используется для визуализации последовательности взаимодействий объектов. Показывает жизненный цикл заданного объекта и взаимодействие актеров (действующих лиц) в рамках некоторого варианта использования, последовательность сообщений которыми они обмениваются.
6. Диаграмма обзора взаимодействия включает часть диаграммы последовательности и конструкции потока управления. Помогает рассмотреть взаимодействие объектов с различных точек зрения.
7. Диаграмма синхронизации - отдельный подвид диаграмм взаимодействия, специализируйющийся на тайминге. Диаграммы этого вида используются для исследования поведения объектов в течение определенного периода времени.

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

UML был создан в результате хаоса вокруг разработки ПО и документации. В 1990-х годах было несколько различных способов представления программных систем. Появилась потребность в более унифицированном способе visual UML представления этих систем, и в результате в 1994-1996 годах он был разработан тремя инженерами-программистами, работающими в Rational Software. Позднее он был принят в виде стандарта в 1997 году и до сих пор остается им, получив всего лишь несколько обновлений.

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

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

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

1. Заявления о языке программирования.
2. Актеры - расписывают роль, которую играет пользователь или любая другая система, взаимодействующая с объектом.
3. Мероприятия, которые должны выполняться по исполнению рабочего контракта и быть представлены в диаграммах.
4. Бизнес-процесс, включающий в себя набор задач, создающих конкретный сервис для клиентов, визуализируемый блок-схемою последовательных действий.
5. Логические и многоразовые программные компоненты.

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

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

Для упрощения моделирования доступны самые разнообразные инструменты моделирования UML, включая IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia.

Использование UML имеет различные виды и в документации по разработке программного обеспечения, и в бизнес-процессах:

1. Эскиз. В этом случае UML-диаграммы используются для передачи различных аспектов и характеристик системы. Однако это только представление верхнего уровня системы и, скорее всего, не будет включать все необходимые детали для выполнения проекта до самого конца.
2. Forward Design - дизайн эскиза выполняется до кодирования приложения. Это делается для лучшего обзора системы или рабочего процесса, который пользователь пытается создать. Многие проблемы дизайна или недостатки могут быть выявлены, что улучшит общее состояние здоровья и благополучия проекта.
3. Обратный дизайн. После написания кода диаграммы UML отображаются как форма документации для разных действий, ролей, участников и рабочих процессов.
4. Светокопия. В этом случае диаграмма служит полной конструкцией, которая требует исключительно фактической реализации системы или программного обеспечения. Часто это делается с помощью инструментов CASE (Computer Aided Software Engineering Tools). Основным недостатком использования инструментов CASE является то, что они требуют определенного уровня знаний, обучения пользователей, а также управления и персонала.

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

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

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

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

Разные типы разбиваются следующим образом:

1. Не все из 14 различных типов UML-диаграмм используются на регулярной основе при документировании систем и архитектур.
2. Принцип Парето, применяется и в отношении использования диаграмм UML.
3. 20 % диаграмм используются разработчиками в 80 % случаев.

Наиболее часто используемые элементы в разработке программного обеспечения:

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

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

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

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

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

1. Функциональные - представлены в качестве вариантов использования.
2. Глагол, описывающий действие.
3. Актеры - для взаимодействия с системой. В роли актера могут быть пользователи, организации или внешней заявкой. Отношения между участниками представляются прямыми стрелками.

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

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

Временная

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

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

Основными компонентами временной диаграммы являются:

1. Lifeline - индивидуальный участник.
2. Временная шкала состояния - единственный жизненный путь может проходить через различные состояния внутри процесса.
3. Ограничение продолжительности - ограничение временного интервала, которое представляет продолжительность необходимого для выполнения ограничения.
4. Ограничение по времени - ограничение временного интервала, в течение которого что-то должно выполняться участником.
5. Появление разрушения - появление сообщения, которое уничтожает отдельного участника и изображает конец жизненного цикла этого участника.

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

Очень простая диаграмма состояния машины была бы в шахматной игре. Типичная шахматная игра состоит из ходов, сделанных Белыми, и движений, сделанных Черными. У Белых есть первый ход, что таким образом инициирует игру. Завершение игры может происходить независимо от того, побеждают ли Белые или Черные. Игра может закончиться матчем, отставкой или ничьей (разные состояния машины). Statecharts находят применение в основном в прямом и обратном UML проектировании различных систем.

Последовательные

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

Чтобы получить более полную информацию, можно рассмотреть пример диаграммы последовательности UML ниже.

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

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

Более конкретно, каждый класс имеет 3 поля: имя вверху, атрибуты прямо под именем, операции/поведение внизу. Связь между различными классами (представленная соединительной линией) составляет диаграмму классов. В приведенном выше примере показана базовая диаграмма классов.

Объектов

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

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

Развертывания

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

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

1. Узлы (сервер приложений и сервер баз данных).
2. Артефакты схема клиентского приложения и базы данных.

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

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

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

Они обычно делятся на следующие основные категории:

1. Бумага и ручка - это легко. Берется бумага и ручка, открывается синтаксический код UML из Интернета и рисуется любой тип диаграммы, который нужен.
2. Онлайн-инструменты - существует несколько онлайн-приложений, которые можно использовать для создания диаграммы. Большинство из них предлагают платную подписку или ограниченное количество диаграмм на свободном уровне.
3. Бесплатные онлайн-инструменты - это почти то же самое, что и платные. Основное различие заключается в том, что платные также предлагают учебные пособия и готовые шаблоны для конкретных диаграмм.
4. Настольное приложение - типичное настольное приложение для использования для диаграмм и почти любая другая диаграмма - это Microsoft Visio. Он предлагает расширенные возможности и функциональность. Единственным недостатком является то, что нужно заплатить за это.

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

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

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

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

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

UML – это язык

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

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

Словарь UML

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

• Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
• Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
• Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
• Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

• Диаграммы, описывающие поведение системы:
• Диаграммы состояний (State diagrams),
• Диаграммы деятельностей (Activity diagrams),
• Диаграммы объектов (Object diagrams),
• Диаграммы последовательностей (Sequence diagrams),
• Диаграммы взаимодействия (Collaboration diagrams);
• Диаграммы, описывающие физическую реализацию системы:
• Диаграммы компонент (Component diagrams);
• Диаграммы развертывания (Deployment diagrams).

Представление управления моделью. Пакеты.

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

Что обеспечивает UML.

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

И последнее…

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