Разработка uml диаграмм. Инструменты для рисования UML-диаграмм. Open source программы

Язык 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. Руководство пользователя

10.4. ДИАГРАММЫ UML

10.4.1. Типы визуальных диаграмм UML

UML позволяет создавать несколько типов визуальных диаграмм:

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

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

Кооперативные диаграммы;

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

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

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

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

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

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

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

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

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

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

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

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

Рис 10.2. Диаграмма последовательности снятия клиентом Джо $20 со счета

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

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения - этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". В то же время осуществляется проверка, что на этом счету лежат, по крайней мере, $20 и из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию "выдать чек и $20 наличными". Наконец, все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

10.4.4. Кооперативные диаграммы

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

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

Рис. 10.3. Кооперативная диаграмма, описывающая процесс снятия денег со счета

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

10.4.5. Диаграммы классов

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

На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Связывающие классы линии показывают взаимодействие между классами.

Рис. 10.4. Диаграмма классов

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

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

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

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

Рис. 10.5. Диаграмма состояний для класса Account

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

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

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

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

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

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

10.4.7. Диаграммы компонент

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

На рис. 10.6 изображена одна из диаграмм компонент для системы ATM. На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением. СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Выделенная темная компонента называется спецификацией пакета и соответствует файлу тела класса ATM на языке C++ (файл с расширением. СРР). Невыделенная компонента также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением. Н). Компонента АТМ. ехе является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки - это исполняемая программа.

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

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

Рис. 10.6. Диаграмма компонент

10.4.8. Диаграммы размещения

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

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

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

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

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

Из книги Microsoft Office автора Леонтьев Виталий Петрович

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

Из книги Компьютер на 100. Начинаем с Windows Vista автора Зозуля Юрий

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

Из книги Эффективное делопроизводство автора Пташинский Владимир Сергеевич

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

Из книги Excel. Мультимедийный курс автора Мединов Олег

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

Из книги Word 2007.Популярный самоучитель автора Краинский И

Построение диаграммы Для первого примера вам понадобится создать таблицу, изображенную на рис. 8.1. Рис. 8.1. Таблица замера температурыМы построим простой график изменения температуры на основе данных этой таблицы.1. Выделите заполненный диапазон в таблице.2. Перейдите на

Из книги Самоучитель работы на компьютере автора Колисниченко Денис Николаевич

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

Из книги Объектно-ориентированный анализ и проектирование с примерами приложений на С++ автора Буч Гради

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

Из книги Технологии программирования автора Камаев В А

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

Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович

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

Из книги OrCAD PSpice. Анализ электрических цепей автора Кеоун Дж.

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

Из книги VBA для чайников автора Каммингс Стив

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

Из книги Самоучитель работы на Macintosh автора Скрылина Софья

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. Выделить нужный диапазон (он может состоять из не смежных прямоугольных

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

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

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

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

Почему нужно несколько видов диаграмм

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

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

Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:

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

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

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

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

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

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

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

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

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

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

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

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

Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм , разделенных на три группы:

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

Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне (появились фреймы и другие визуальные улучшения), немного усовершенствовалась нотация , некоторые диаграммы получили новые наименования.

Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности UML , а лишь познакомить с этим языком, дать первоначальное представление об этой технологии.

Итак, мы кратко рассмотрим такие виды диаграмм, как:

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

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

Диаграмма прецедентов (use case diagram)

Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :

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

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

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

Рис. 2.1.

Тот же внимательный читатель мог заметить промелькнувшее в определении эктора слово "прецедент". Что же это такое? Этот вопрос заинтересует нас еще больше, если вспомнить, что сейчас мы говорим о диаграмме прецедентов . Итак,

Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).

Определение вполне понятное и исчерпывающее, но его можно еще немного уточнить, воспользовавшись тем же Zicom Mentor "ом:

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

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

формирование общих требований к поведению проектируемой системы;

разработка концептуальной модели системы для ее последующей детализации;

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

11.1. Структура Унифицированного языка моделирования

Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:

UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Последнюю официальную спецификацию языка можно найти на сайте www.omg.org .

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

Рис. 11.1. Структура UML

11.2. Семантика и синтаксис UML

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

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

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

11.3. Нотация UML

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

В UML определено три типа сущностей :

Структурная – абстракция, являющаяся отражением концептуального или физического объекта;

Группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;

Поясняющая (аннотационная) – комментарий к элементу диаграммы.

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

Таблица 11.1. Сущности

Тип	Наименование	Обозначение	Определение (семантика)
Структурная	(class)		Множество объектов, имеющих общую структуру и поведение
	(object)		Абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности)
	(actor)	Инженер службы пути	Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
	(use case)		Описание выполняемых системой действий, которая приводит к значимому для актера результату
	(state)		Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
	Кооперация (collaboration)		Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
	(component)		Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
	(interface)	iРасчет	Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
	(node)		Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Группирующая	(package)		Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
	(fragment)		Область специфического взаимодействия экземпляров актеров и объектов
	(activity partition)		Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.)
	(interruptible activity region)		Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации
Поясняющая	Примечание (comment)		Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией

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

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

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

Таблица 11.3. Отношения

Наименование	Обозначение	Определение (семантика)
Ассоциация (association)		Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения
Агрегация (aggregation)		Подвид ассоциации, описывающей связь "часть"–"целое", в котором "часть" может существовать отдельно от "целого". Ромб указывается со стороны "целого". Отношение указывается только между сущностями одного типа
Композиция (composition)		Подвид агрегации, в которой "части" не могут существовать отдельно от "целого". Как правило, "части" создаются и уничтожаются одновременно с "целым"
Зависимость (dependency)		Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность
Обобщение (generalization)		Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа
Реализация (realization)		Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)

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

- * – любое количество экземпляров, в том числе и ни одного;

Целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

Диапазон целых неотрицательных чисел "первое число.. второе число" (например: 1..5, 2..10 или 0..5);

Диапазон чисел от конкретного начального значения до произвольного конечного "первое число.. *" (например: 1..*, 5..* или 0..*);

Перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 11.4. Механизмы расширения

Наименование	Обозначение	Определение (семантика)
Стереотип (stereotype)	« »	Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс)
Сторожевое условие (guard condition)		Логическое условие (например: или [идентификация выполнена])
Ограничение (constraint)	{ }	Правило, ограничивающее семантику элемента модели (например, {время выполнения менее 10 мс})
Помеченное значение (tagged value)	{ }	Новое или уточняющее свойство элемента нотации (например: {version = 3.2})

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


a) стандартное обозначение		б) стандартное обозначение с текстовым стереотипом		в) графический стереотип

Рис. 11.2. Примеры стандартного и стереотипного отображения класса

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

Таблица 11.5. Диаграммы

Диаграмма			Назначение
				по степени физической реализации	по отображению динамики	по отображаемому аспекту
(use case)			Отображает функции системы, взаимодействие между актерами и функциями	Логическая	Статическая	Функциональная
(class)			Отображает набор классов, интерфейсов и отношений между ними	Логическая или физическая	Статическая	Функционально-информационная
(package)			Отображает набор пакетов и отношений между ними	Логическая или физическая	Статическая	Компонентная
Поведения (behavior)	(state machine)		Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла	Логическая	Динамическая	Поведенческая
	(activity)		Отображает бизнес-процессы в системе (описание алгоритмов поведения)
	Взаимодействия (interaction)	(sequence)	Отображает последовательность передачи сообщений между объектами и актерами
		(communication)	Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами
Реализации (implementation)	(component)		Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними	Физическая	Статическая	Компонентная
	(deployment)		Отображает размещение компонентов по узлам сети, а также ее конфигурацию

Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы:

Диаграмму объектов (object diagram) - аналогична , но вместо классов отображаются объекты;

Диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;

Композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;

Профильную диаграмму (profile diagram) - аналогична с описанием классов, входящих в них;

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

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

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

Таблица 11.6. Связь моделей и диаграмм

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

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

4. Дайте определение понятию " ".

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

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

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

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

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

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

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

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

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

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

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

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