ЛекUML

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

Ассоциация с направлением навигации

иогрничением

видимости

Ассоциация "многие ко многим"

Обратите внимание, что, согласно семантическим правилам UML, ограничение видимости полюса pwd распространяется на объекты класса Workgroup, но не на объекты класса User — непосредственно связанные объекты всегда видят друг друга. Объект класса User может использовать интерфейс pwd, предоставляемый классом Password — стрелка навигации разрешает ему это, но объект класса Workgroup не может использовать интерфейс pwd — значение видимости private (знак –) запрещает ему это.

Упорядоченность объектов на полюсе ассоциации. Ели кратность полюса лежит в диапазоне 0..1, то проблемы упорядоченности не возникает — на данном полюсе связи, возможно, имеется один объект, но не более того. При иных кратностях объектов может быть несколько, т. е. полюс связи присоединен к множеству объектов. По умолчанию множество объектов, присоединенных к данному полюсу связи, считается неупорядоченным. Если необходимо указать, что это множество упорядочено, то нужно наложить соответствующее ограничение на полюс ассоциации. В качестве ограничения используется одно из двух ключевых слов:

ordered (или sorted) если множество упорядочено;

unordered, если не упорядочено.

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

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

Рассмотрим ситуацию, когда два класса связаны ассоциацией "один ко многим" (именно этот случай имеет место в данном примере). Такая ассоциация доставляет для каждого экземпляра класса, находящегося на полюсе "один" множество (иногда большое) объектов класса, находящегося на полюсе "много". Например, по экземпляру многоугольника можно получить множество его вершин. Однако часто возникают ситуации, когда нужно получить не все множество ассоциированных объектов, а некоторое небольшое подмножество, чаще всего один конкретный объект. Чтобы выделить из множества один конкретный элемент, нужно располагать информацией, однозначно идентифицирующей этот элемент. Такую информацию принято называть ключом. Например, номер вершины в многоугольнике можно считать ключом и тогда задача ставится так: по многоугольнику и номеру вершины получить вершину. Всегда можно применить следующее тривиальное решение: хранить ключ в самом объекте в качестве атрибута и, получив множество объектов, перебирать их все последовательно до тех пор, пока не найдется тот, который имеет искомое значение ключа. Такой прием называется линейным поиском. Для многоугольников, у которых не очень много вершин, данный способ может быть вполне приемлемым. Но в других случаях, когда к полюсу "много" присоединено действительно много объектов, линейный поиск слишком неэффективен. Известно множество программных решений, позволяющих эффективно выделить (найти в множестве) объект по ключу: сортированные массивы, таблицы расстановки (хэштаблицы), деревья сортировки, внешние индексы и др. Эти приемы обобщены в UML понятием квалификатора. Квалификатор полюса ассоциации — это атрибут (или несколько атрибутов) ассоциации, значение которого (которых) позволяет выделить один (или несколько) объектов класса, присоединенного к данному полюсу ассоциации. Квалификатор изображается в виде небольшого прямоугольника на полюсе ассоциации, примыкающего к прямоугольнику класса. Внутри этого прямоугольника (или рядом с ним) указывается имена и, возможно, типы атрибутов квалификатора. Описание квалифицирующего атрибута ассоциации имеет такой же синтаксис, что и описание обычного атрибута класса, только оно не может содержать начального значения. Квалификатор может присутствовать только на том полюсе ассоциации, который имеет кратность "много", поэтому, если на полюсе ассоциации с квалификатором задана кратность, то она указывает не допустимую мощность множества объектов, присоединенных к полюсу связи, а допустимую мощность того подмножества, которое определяется при задании значений атрибутов

Класс ассоциации

Job

part : Percent

Position Person

Линия ассоциации

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

Трехполюсная

ассоциация

*

Project

4.2.7.Интерфейсы и роли

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

Между интерфейсами и другими классификаторами, в частности классами, на диаграмме классов применяются два отношения:

классификатор (в частности, класс) использует интерфейс — это показывается с

помощью зависимости со стереотипом «call»;

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

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

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

4.2.10. Пакеты

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

Пакет задает пространство имен. Package::Entity

Пакет может содержать любые элементы, в том числе пакеты

Пакет в UML – логическое понятие модели, не имеет отношения к пакетам Java ☺

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

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

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

сравнительно редко. Большинство инструментов не поддерживает отдельного режима для рисования диаграмм объектов: на диаграмме классов можно разместить только объекты (без классов) и тем самым она станет диаграммой объектов Закончим обсуждение диаграмм классов (и объектов) — серией элементарных советов по практическому моделированию (взято из Буча).

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

Не обязательно включать в модель все классы сразу. На первых итерациях достаточно идентифицировать очень небольшую (10%) долю всех классов системы.

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

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

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

4.3. Диаграммы реализации

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

структуры компонентов в приложении; структуры используемых вычислительных ресурсов.

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

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

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

интерфейсы; классы; объекты.

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

ассоциация (главным образом в форме композиции); реализация.

4.3.2. Компонент

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

Компонент нетривиален. Это нечто более сложное и объемное, чем фрагмент кода или одиночный класс.

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

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

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

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

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

Стандартные стереотипы компонентов

Рассмотрим пример информационной системы отдела кадров. Какие компоненты разумно выделить в этой системе? Основное назначение системы — хранить данные о кадрах и выполнять по указанию пользователя некоторые операции с этими данными. Анализирую состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД для управления данными. С точки зрения проектирования информационной системы отдела кадров целесообразно считать используемую СУБД готовым компонентом. Мы можем не