Стереотип» видимость имя (список параметров): возвращаемый тип {строка свойств}.

Видимость операции задаётся так же, как и для атрибута.

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

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

Синтаксис записи параметров:

<вид параметра> <имя параметра>: <выражение типа> = <значение по умолчанию>.

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

В строке свойств даются описания дополнительных свойств операции. Например, если операция не должна изменять состояние системы при вызове, то ставится ключевое слово query (запрос). Может также указываться свойство параллелизма конструкцией вида {concurrency = имя}. Здесь имя – одно из ключевых слов:

· sequential ( последовательная, по умолчанию );

· concurrent (параллельная, её можно без каких-либо ограничений выполнять параллельно с другими операциями);

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

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

Если область действия операции распространяется на все объекты класса (класс целиком), то операция подчёркивается (аналогично атрибуту).

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

 

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

 

 

Рисунок 3 – Пример более детального обозначения класса

 

Операции могут быть сигналами. Сигнал является фундаментальным видом коммуникации, имеет характер одностороннего сообщения, идущего от одного объекта к другому. Поэтому операция по сигналу не имеет возвращаемого значения. Перед ней ставится стереотип «signal». Более подробно сигналы, события и сообщения будут изучаться далее.

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

· отношения зависимости (dependency relationship);

· отношения ассоциации (association relationship);

· отношения обобщения (generalization relationship);

· отношения реализации (realization relationship).

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

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

 

 

Рисунок 4 – Зависимости между классами

 

На рисунке 4 класс А вызывает операции классов В и С; класс С создаёт экземпляры класса В, пользуясь его конструктором; операция класса D может иметь доступ в порядке исключения к содержимому класса В.

В таблице приведены стандартные зависимости, используемые в UML.

Стандартные зависимости <стереотипы>:

become	превращать объект класса-клиента в объект класса-поставщика
bind	связывать (клиент создаёт новый элемент с помощью параметризованного шаблона поставщика)
call	вызывать операцию на исполнение
copy	копировать (создать независимую копию клиента)
create	создавать (использовать конструктор поставщика)
derive	выводить (атрибуты клиента вычисляются по атрибутам поставщика)
extend	расширять (клиент расширяет функциональность поставщика)
friend	быть дружественным (клиент имеет исключительный доступ к содержимому поставщика)
import	импортировать (клиент импортирует атрибуты и операции поставщика)
include	включать (клиент включает в себя функциональность поставщика)
instanceOf	являться экземпляром (клиент является частным примером поставщика)
instantiate	создать экземпляр (клиент создаёт с помощью конструктора поставщика экземпляр поставщика и инициализирует его)
refine	уточнять (клиент является уточнением поставщика по дополнительной информации)
send	отправить (клиент отправляет сигнал поставщику)
trace	трассировать (клиент является более новой версией поставщика)
use	использовать (клиент использует услуги поставщика для реализации своего поведения).

 

Отношение ассоциации (ассоциация, association) – описывает связи между экземплярами классов (объектами) - в отличие от зависимости, которая относится к классу в целом. В ассоциации проставляется множественность участия экземпляров в связи (один или много).

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

На рисунке 5 экземпляром отношения является, например, пара «Иванов – ООО «Ракурс»».

 

 

Рисунок 5 – Бинарная ассоциация

 

 

В n –арной ассоциации участвуют три и более класса, при этом один класс может участ-

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

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

 

 

Рисунок 6 – Трёхарная ассоциация

 

Важной характеристикой ассоциации является кратность (множественность и обязательность связи). Обозначение “*” обозначает “0..*”, т.е. необязательность связи «много».

В более сложном случае ассоциация может быть классом (класс – ассоциация, association class), в нём присутствуют и свойства класса, и свойства ассоциации. Экземплярами такого класса являются связи, в которых имеются не только ссылки на объекты, но и конкретные значения атрибутов связи.

Классы – ассоциации могут иметь операции, изменяющие атрибуты связи, могут участвовать в различных ассоциациях, но сами с собой ассоциации они иметь не могут!

Обозначение класса - ассоциации показаны на рисунке 7.

 

 

Рисунок 7 – Пример класса-ассоциации

 

Такой подход уместен при связи «многие ко многим». Иначе можно было бы включить оклад в атрибуты одного из классов. Однако, если требуется отобразить историю окладов (дата/оклад) т.е. несколько экземпляров связей между одними и теми же объектами, то класс – ассоциации уже использовать нельзя! Нужно вводить обычный класс с атрибутами (см. рисунок 8).

 

		Роль фирмы

 

 

Рисунок 8 – Пример с многими экземплярами связей между двумя объектами

 

 

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

Отношение агрегации (агрегация, aggregation) – один из классов (агрегат) состоит из других классов или его характеристиками являются другие классы (отношение часть/ целое, part of). Это отношение является фундаментальным при моделировании сложной системы, позволяет декомпозировать систему на составные части. В агрегации принцип наследования не соблюдается. Каждая часть или характеристика обладает своими атрибутами и поведением. Агрегация в UML обозначается ромбом, примыкающим к агрегату (рисунок 9). У полюсов связей может быть указана множественность. Любая часть может входить в несколько различных агрегатов.

 

 

 

Рисунок 9 - Агрегат и его части

 

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

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

 

 

Главное меню

 

 

Рисунок 10 – Отношение композиции

 

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

Единственное ограничение, которое вносит агрегация в ассоциацию – отсутствие цикличности связи, так как класс не может содержаться сам в себе.

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

 

 

 

 

Рисунок 11 - Пример обозначения обобщения

В UML может применяться и другой стиль оформления обобщения – бинарный, в котором для пар потомок-предок используется отдельная наклонная линия (рисунок 12).

 

 

Рисунок 12 – Бинарный стиль обозначения обобщения с перекрытием

 

Многоточие означает, что все возможные потомки пока не перечислены и могут появиться другие потомки (свойство «неполный», incomplete). Отсутствие многоточия говорит о полном перечислении потомков (свойство «полный», complete). Если эллипс может иметь потомком окружность (например, при равенстве полуосей), то говорят о свойстве «перекрытие», overlapping – оно обязательно обозначается, как показано на рисунке. По умолчанию считается, что перекрытие отсутствует (свойство «раздельный», disjoint).

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

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

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

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

На рисунке 13 изображены два варианта программной реализации спецификации блока выбора решения на экране: выпадающее меню с опциями выбора в виде строки и набор радиокнопок альтернативного выбора, помечаемых курсором. Спецификация выбора задаётся классом интерфейсного типа ChoiceBlock без раздела атрибутов. В этом классе определены две видимые операции: setDefault – Установить значение опции выбора по умолчанию и getChoice – Получить значение опции выбора. Классы реализации спецификации PopUpMenu и RadioButtonArray объявляют эти же операции, но с более конкретными аргументами выбора и возвращаемыми значениями String (Строка) и Button (Кнопка) соответственно. Блоки выбора решения связаны бинарной ассоциацией с соответствующими классами единичного выбора Choice, String и Button.

 

 

.

 

 

Рисунок 13 - Отношение реализации

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

Важным частным случаем отношения реализации является реализация варианта использования или отдельной операции в виде кооперации (collaboration) объектов (рис. 14).

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

 

 

 

Рисунок 14 - Реализация варианта использования при помощи кооперации

 

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

1) граничные (boundary) классы: объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов, упоминавшихся ранее);

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

3) классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.;

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

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

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

Рекомендуется для избежания конфликта имён в модели системы использовать только один вид группировки.

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

Система (стереотип «system») – это корневая подсистема в иерархии пакетов. Она является единственной сущностью, которая не может содержаться в других пакетах. В пакете система содержатся все остальные подсистемы и модели.

Подсистема (стереотип «subsystem») – это часть системы, которая может быть выделена разработчиком по тому или иному признаку (обычно функциональному или территориальному). Представляется отдельным пакетом. У подсистемы есть собственная спецификация и программная реализация. Разбиение на подсистемы производится для сложных систем, реализация которых основана на использовании большого количества классов. Практически все подсистемы любого уровня детализации взаимозависимы. Количество уровней иерархии в декомпозиции подсистем на подсистемы языком UML не ограничивается.

Модель (стереотип «model») – некоторое абстрактное представление системы, использующее ту или иную точку зрения разработчика (определённые свойства системы). Моделей может быть множество, они могут быть взаимозависимы, а также вкладываться друг в друга. Каждая модель представляется отдельным пакетом. Все они содержатся в пакете система, могут также содержаться в пакетах подсистема и модель более высокого уровня.

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

Перед именем элемента, например, класса может ставиться имя пакета. Оно отделяется двойным двоеточием. Пример: displayWindow: WindowingSystem:: GraphicWindows:: Window (указаны два пакета перед именем класса Window, причем пакет GraphicWindows входит в состав пакета). Так отображается иерархия пакетов.

Пакет изображается в виде большого прямоугольника, к левому углу которого прикреплён другой прямоугольник вида «закладки» (подобно изображению папки в операционной системе Windows). Если содержимое пакета не раскрывается, то внутри большого прямоугольника ставится имя пакета. Иначе имя пакета помещается в закладку. Над именем пакета может располагаться строка стереотипа в угловых кавычках. Пример диаграммы пакетов представлен на рисунке 15.

Рисунок 15 – Пример диаграммы пакетов

На рисунке изображена в виде пакета со стереотипом «подсистема» часть системы, формирующая отчёты по продажам по запросам пользователей. Этот пакет содержит несколько пакетов, связанных отношением зависимости (пунктирная стрелка) с внешними пакетами. Пакет Интерфейс пользователя использует стандартные компоненты внешнего по отношению к подсистеме пакета Оконный интерфейс (формы, элементы управления и методы работы с ними, определённые выбранной системой программирования и операционной системой). Кроме того, для формирования отчётов о продажах требуется расчёт показателей, реализуемый двумя способами (вариантами): с помощью электронных таблиц MS Excel и с помощью СУБД MS Access. На диаграмме пакетов это отображено абстрактным пакетом Расчёт показателей, являющегося обобщением двух конкретных пакетов Расчёт по электронным таблицам и Расчёт по таблицам БД. Все эти пакеты связаны отношением зависимости с соответствующими внешними пакетами. Имена абстрактных пакетов выделены курсивом.