Краткие теоретические сведения

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

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

Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.

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

 

Рисунок 1 - Варианты графического изображения класса на диаграмме классов

 

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

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

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

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

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

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

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

Одним из несомненных достоинств языка UML является наличие механизмов расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Так, в рамках одного из них, а именно профиля для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) предложено три специальных графических примитива, которые могут быть использованы для уточнения смысла отдельных классов:

· Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом <<control>> (рисунок 2,а);

· Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>> (рисунок 2,б);

· Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>> (рисунок 66,в).

Рисунок 2 - Графическое изображение классов для моделирования программного обеспечения

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

Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом <<interface>> (рисунок 3).

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

 

Рисунок 3 - Примеры графического изображения интерфейсов на диаграммах классов

 

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

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

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

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

· Отношение агрегации (aggregation relationship);

· Отношение композиции (composition relationship).

Ассоциация (association) - семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.

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

Имя ассоциации - необязательный элемент ее обозначения. Однако если оно задано, то записывается с заглавной буквы рядом с линией ассоциации. Наиболее простой случай данного отношения - бинарная ассоциация (binary association), которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации - рефлексивная ассоциация, которая связывает класс с самим собой. Ненаправленная бинарная ассоциация изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации. Это показано на (рисунок 4).

Рисунок 4 - Графическое изображение ненаправленной бинарной ассоциации между классами

 

Направленная бинарная ассоциация изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой – вторым (рисунок 5).

 

Рисунок 5 - Графическое изображение направленной бинарной ассоциации между классами

 

Частный случай отношения ассоциации - так называемая исключающая ассоциация (Xor-association). Из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации (рисунок 6) рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

 

 

Рисунок 6 - Графическое изображение исключающей ассоциации между тремя классами

 

Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n-арной ассоциацией. Графически n-арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Сам же ромб соединяется с символами классов сплошными линиями. Имя n-арной ассоциации записывается рядом с ромбом соответствующей ассоциации (рисунок 7).

Рисунок 7 - Графическое изображение тернарной ассоциации между тремя классами

 

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

На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рисунок 8). Стрелка указывает на более общий класс (класс-предок или суперкласс), а ее начало - на более специальный класс (класс-потомок или подкласс).

Рисунок 8 - Графическое изображение отношения обобщения в языке UML

 

От одного класса-предка одновременно могут наследовать несколько классов-потомков, что отражает таксономический характер данного отношения (рисунок 9).

Рисунок 9 - Пример графического изображения отношения обобщения для нескольких классов-потомков

 

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

Рисунок 10 - Альтернативный вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

 

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

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:

· {complete} - означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может.

· {incomplete} - означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно разработчик восполнит их перечень, не изменяя уже построенную диаграмму.

· {disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.

· {overlapping} - случай, противоположный предыдущему. А именно, предполагается, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

Рисунок 11 - Вариант уточненного графического изображения отношения обобщения классов с использованием строки-ограничения

 

Агрегация (aggregation) - специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью.

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

 

Рисунок 12 - Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК

 

Композиция (composition) - разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого. Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит. Остальные классы являются его "частями" (рисунок 13).

 

 

Рисунок 13- Диаграмма классов для иллюстрации отношения композиции на примере класса-композита Окно программы

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

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

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

В контексте языка UML любой объект является экземпляром класса, описанного в модели и представленного на диаграмме классов. Объект создается на этапе реализации модели или выполнения программы. Он имеет собственное имя и конкретные значения атрибутов.

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

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

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

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

Рисунок 28 - Графическое изображение активного объекта (слева) на диаграмме кооперации

 

Мультиобъект(multiobject) представляет собой множество анонимных объектов, которые могут быть образованы на основе одного класса. Мультиобъект изображается двумя прямоугольниками, один из которых выступает из-за верхней правой вершины другого (рисунок 29,а). При этом стрелка взаимосвязи относится ко всему множеству объектов, которые обозначает данный мультиобъект. На диаграмме кооперации может быть явно указано отношение агрегации (композиции) между мультиобъектом и отдельным объектом из его множества (рисунок 29,б).

Рисунок 29 - Графическое изображение мультиобъектов на диаграмме кооперации

 

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

Рисунок 30 - Графическое изображение составного объекта на диаграмме кооперации

 

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

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

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

Рисунок 31 - Графическое изображение различных типов сообщений на диаграмме кооперации

 

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

· Сплошная линия с V-образной стрелкой (рисунок 31,б) обозначает асинхронное сообщение в простом потоке управления. В этом случае клиент передает асинхронное сообщение и продолжает выполнять свою деятельность, не ожидая ответа от сервера;

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

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

В языке UML определены следующие стереотипы сообщений:

· <<call>>(вызвать) – сообщение, требующее вызова операции или процедуры объекта-получателя. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у пославшего это сообщение объекта;

· <<return>>(возвратить) – сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;

· <<create>>(создать) – сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может стать активным (ему передается поток управления), а может остаться пассивным;

· <<destroy>>(уничтожить) – сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;

· <<send>>(послать) – обозначает посылку другому объекту сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.

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

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