Словарь uml

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

Сущности – это абстракции, являющиеся основными элементами моделей.

Имеется 4 типа сущностей:

• Структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел)

• Поведенческие (взаимодействие, состояние)

• Группирующие (пакеты)

• Аннотационные (комментарии)

Каждый вид сущностей имеет свое графическое представление.

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

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

Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение между вида «целое» - «часть». Графически оно выделяется с помощью ромбика на конце около сущности - целое.

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

Для каждого атрибута класса можно задать видимость (visibility). Эта характеристика показывает, доступен ли атрибут для других классов. В UML определены следующие уровни видимости атрибутов:

Открытый (public) – атрибут виден для любого другого класса (объекта);

Защищенный (protected) – атрибут виден для потомков данного класса;

Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

Отношения

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

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

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

Рисунок 1 Рисунок 2

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

Диаграммы классов создаются при логическом моделировании ПС и служат для следующих целей:

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

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

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

• Для моделирования логики программных компонент (будет описано в последующих статьях).

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

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

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

Целями анализа и моделирования требований являются:

• достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;

• достижение лучшего понимания разработчиками поведения ПС;

• ограничение системной функциональности;

• создание базиса для планирования разработки проекта;

• определение пользовательского интерфейса.

Для достижения этих целей используются диаграммы вариантов использования UML (Use case diagrams).

Общие сведения о диаграммах вариантов использования

На диаграммах вариантов использования (ВИ) изображаются актеры и варианты использования, между которыми существуют отношения. Здесь можно показывать и другие элементы UML (например, классы могут показывать, какие сущности порождаются или используются в конкретных ВИ, рис.1).

Рисунок 1

Рисунок 2

Рисунок 3

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

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

При взаимодействии актера с системой последняя выполняет ряд работ, которые образуют вариант использования системы (use case). Каждый актер может использовать систему по-разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе (которое может быть разбито на несколько более мелких). ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент.

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

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

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

Ассоциация – единственно возможная связь между актером и ВИ. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. На рис.2 оператор инициирует начало выполнения ВИ открытия нового счета.

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

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

Отношение включения, помечаемое стереотипом <>, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но не включаемый. Включение показывается пунктирной стрелкой, направленной от базового ВИ к включаемому (см. рис.2).

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

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

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

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

• детальное описание потоков событий, определенных в ВИ;

• нахождение классов, которые реализуют потоки событий, определенные в ВИ;

• распределение поведения, описываемого ВИ, по этим классам;

• определение ответственностей, атрибутов и ассоциаций классов;

• описание поведения объектов в виде конечного автомата.

• Диаграммы последовательностей (Sequence diagrams)

• На диаграммах последовательностей, иногда называемых сценариями, показываются объекты и сообщения, которыми они обмениваются. Каждый объект изображается в виде вертикальной линии («линии жизни» объекта). По вертикали сверху вниз направлена временная ось. Сообщение, показываемое в виде стрелки от объекта к объекту, соответствует вызову операции соответствующего класса (см. рис.). Таким образом, на диаграмме можно показать поток сообщений во времени (сценарий). С помощью диаграмм этого вида можно описать как основной, так и альтернативные потоки событий для ВИ.

Диаграммы кооперации (Collaboration Diagrams)

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

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

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

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

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