Кроме внутреннего устройства или структуры классов на диаграмме классов указываются различные отношения между классами. В стандарте UML определены следующие типы отношений между классами (пакетами, интерфейсами): ассоциация (равноправные классы), обобщение (наследование), зависимость, реализация, агрегация (включение по ссылке), композиция (физическое включение).
Каждая связь может быть именованной и может быть указана множественность связи.
Отношение ассоциации – с одной стороны, самый общий и самый слабый тип связи, а с другой, один из самых важных и сложных типов связи. Графически ассоциация изображается в виде сплошной линии, соединяющей классы (либо класс сам с собой).
Отношение обобщения - показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Графически обобщение представляется линией с пустым треугольником у супертипа.
Отношение зависимости - это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причем обратное не обязательно. Графически представляется пунктирной стрелкой, идущей от зависимого элемента к тому, от которого он зависит.
Отношение реализации — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация – отношение целое-часть. Графически реализация представляется также как и наследование, но с пунктирной линией(стрелка идет от клиента).
Отношение агрегации задает более сильную форму однонаправленной ассоциации, которая устанавливает соотношение частей и целого. Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет. Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
Отношение композиции показывает физическое вхождение части в целое, т.е. удаляется целое – удаляются и все его части. Также называется, как агрегация по значению. Графически представляется как и агрегация, но с закрашенным ромбиком.
Целое композиции должно иметь мультипликатор 0..1 или 1, что показывает, что часть является частью только одного целого. В агрегации же может быть любой мультипликатор.Приведём наглядный пример. Комната является частью квартиры, следовательно здесь подходит композиция, потому что комната без квартиры существовать не может. А, например, мебель не является неотъемлемой частью квартиры, но в то же время, квартира содержит мебель, поэтому следует использовать агрегацию.
Классы ассоциаций.
(В ассоциации между двумя классами сама ассоциация также может иметь свойства).
Классы ассоциаций позволяют определить для ассоциаций атрибуты, операции и другие свойства. Рассмотрим это на примере.
(тут должна была быть диаграмма, но на неё можно забить -- прим. копипастера)
Из данной диаграммы видно, что Личность(Person) может работать только в одной Компании (Company). При этом необходимо каким-то образом хранить информацию относительно периода времени, в течение которого каждый служащий работает в каждой Компании.
Это можно сделать, дополнив ассоциацию атрибутом «интервал Времени». Можно было бы включить этот атрибут в класс Личность. Однако на самом деле он характеризует не Личность, а её связь с Компанией, которая будет меняться при смене работодателя.
Можно в этой ситуации поступить иначе. Например, преобразовать Работу в обычный класс. Получилось бы так:
(тут должна была быть вторая диаграмма, но на неё тоже можно забить -- прим. копипастера)
Как видите, множественность при этом также подвергается соответствующему преобразованию. (После преобразования роль «работодатель» становится производной (/)).
Что же хорошего дает нам класс ассоциаций? (В качестве компенсации за необходимость изучения и заполнения ещё одной нотации.)
Класс ассоциаций дает возможность определить дополнительное ограничение. А именно: двум участвующим в ассоциации объектам может соответствовать только один объект класс ассоциаций.
В образце задания на этапе анализа также используются классы ассоциаций.
Класс - ассоциацию можно присоединить только одинаковые (или почти одинаковые) свойства у нескольких классов – ассоциаций. (чо?) Можно, например, поступить так в этой ситуации: определить обычный класс С, а затем сделать каждый класс – ассоциацию, которому нужны определенные свойства, наследником C (или использовать C как тип атрибута в классах - ассоциациях).
Итак, класс – ассоциация – это место, где хранятся атрибуты (операции), которые относятся к отношению ассоциация.
(Я просто невероятно прошарился по этому вопросу - прим. читателя)
43. Диаграммы вариантов использования, реализации вариантов использования.
Диаграммы вариантов использования (Use Case Diagram) определяют поведение системы с точки зрения пользователя и показывают, что система будет делать в процессе своего функционирования, поэтому являются основой для общения с заказчиком.
В состав диаграммы Use Case входят следующие элементы: прецеденты (варианты использования), актеры (действующие лица) и отношения между ними (связи). Рассмотрим эти элементы.
Актеры представляют внешний мир, нуждающийся в работе системы. А варианты использования представляют действия, выполняемые системой в интересах актеров.
Следует различать актеров и пользователей системы. Пользователь – это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Обратное тоже справедливо – одним актером могут быть разные пользователи.
Прецедент – это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для актера видимый результат. Поэтому каждый Use Case задает определенный путь использования системы, а набор всех элементов Use Case определяет полные функциональные возможности системы, т.е. определяет границы системы. Название вариантов использования рекомендуется начинать с глагола (например, создать, редактировать, управлять, измерить).
Действующие лица (актеры) вовсе не обязаны быть людьми (хотя, и изображаются стилизованной человеческой фигурой). Актёром может быть внешняя система, которой необходима некоторая информация от моделируемой ПС (базы данных тоже иногда изображают в виде актера).
Бывает ещё один тип актера – время. Время становится актером, если от него зависит запуск каких–либо событий в системе. Например, система должна в определенное время (скажем, в полночь) выполнять какие-либо служебные функции (например, копировать информацию или настраивать какие-то параметры). И так как время не подлежит нашему контролю, то оно является актером.
Что главное в диаграммах Use Case? Главное – они не зависят от реализации. Вариантов использования в диаграммах не должно быть слишком много, иначе теряется преимущество простоты. Их должно быть столько, чтобы пользователь (или заказчик) смог увидеть всю систему целиком на самом высоком уровне. Как показала практика, модель типичной системе обычно содержит от 15 до 50 прецедентов.
В процессе развития модели основные варианты использования могут разбиваться на два и больше других вариантов использования. Можно также объединять похожие варианты в пакеты. Каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой.
Реализации вариантов использования (или кооперации), как правило, фиксируются на Логическом уровне представления модели и имеют те же имена, что и варианты использования в Use Case Model. Обозначения их также схожи, соединяются отношением “реализация”.
Диаграммы взаимодействий.
Диаграммы языка UML, которые отражают взаимодействие объектов друг с другом, получили название диаграмм взаимодействий. Они бывают двух видов: диаграммы последовательностей (Sequence Diagrams) и диаграммы сотрудничества (Collaboration Diagrams).
Оба вида диаграмм служат для моделирования поведения объектов, т.е. с их помощью можно смоделировать динамические аспекты системы. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма сотрудничества – на структурной организации посылающих и принимающих сообщения объектов. Обе диаграммы преобразуются друг в друга без потери информации.
На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия.
Каждый объект изображается пунктирной вертикальной линией жизни и прямоугольником в верхней части своей линии жизни (рис. 8.1). Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием.
Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения.
Чтобы явно выделить активность объектов, в языке UML применяется фокус управления (focus of control) в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало активности, а ее нижняя сторона -окончание активности.
Типы сообщений в диаграмме вариантов использования: 
Особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи - потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений. последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров.
Кооперация может быть представлена на двух уровнях:
● На уровне спецификации - показывает роли классификаторов и роли ассоциаций в рассматриваемом взаимодействии.
● На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации. При этом связи дополняются стрелками сообщений.
Простой класс на диаграмме кооперации обозначается прямоугольником класса, внутри которого записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Связь (link) является экземпляром или примером произвольной ассоциации. Связь как элемент языка UML может иметь место между двумя и более объектами. На каждом из концов этой линии могут быть явно указаны имена ролей данной ассоциации. Рядом с линией в ее средней части может записываться имя соответствующей ассоциации.
