Вернуться на страницу <Model Vision Studium>
В начало

Технология моделирования UML

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

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

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

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

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

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

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

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

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

Диаграммы классов (class diagrams)

1. Основные понятия ООП

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

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

Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением.

ООП характеризуется тремя основными свойствами:

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

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

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

2. Назначение диаграмм классов

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

3. Класс

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

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

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

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

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

Так как иерархия пакетов может иметь глубину вложенности большую, чем 1, то путь к классу может содержать более чем один пакет, при этом путь начинается от корня иерархии пакетов:

В секции имени класса могут находиться (по порядку сверху вниз):

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

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

Атрибут

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

У атрибута должен быть тип (type expression), который может представлять собой простой тип или быть сложным, как например:

CArray<CString *, CPoint *>

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

Атрибут изображается в виде текстовой строки, отражающей различные его свойства:

• Признак видимости имеет С++ семантику видимости членов класса:
• Общий атрибут (public) (обозначается символом +) означает, что любая сущность, имеющая доступ к объекту определяемого класса, имеет доступ и к этому атрибуту.
• Защищенный атрибут (protected) (обозначается символом #) означает, что к атрибуту имеют доступ только методы данного класса и его потомков.
• Секретный атрибут (private) (обозначается символом -) означает, что атрибут доступен только методам класса.
• Символ области видимости может изображаться ключевым словом “public", "private” или “protected” или может быть опущен. Это означает, что область видимости не показывается (а не то, что она не определена или “public” по умолчанию).
• Имя - это идентификатор, представляющий имя атрибута.
• Тип - зависящее от языка реализации описание типа атрибута.
• Значение по умолчанию - зависящее от языка реализации выражение, задающее начальное значение для атрибута вновь созданного объекта. Эта часть определения атрибута не обязательна.
• Свойства - строка дополнительных свойств элемента (необязательная часть). Если свойства не указываются, скобки {} опускаются. Примером свойства может служить имя автора:

По умолчанию атрибут является изменяемым. Указав в его свойствах пометку {frozen} можно объявить атрибут неизменяемым.

Для атрибута можно указывать его множественность. Если она не обозначена, то предполагается, что атрибут может хранить ровно одно значение. Множественность может быть определена в квадратных скобках сразу после имени атрибута:

coords[3]: integer

Операция

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

Операция изображается текстовой строкой, имеющей следующую грамматику:

• Признак видимости, имя и свойства имеют тот же смысл, что и для атрибута.
• Список параметров - список формальных параметров, разделенных запятыми: <имя>:<тип>=<значение по умолчанию>
• Имя - имя параметра.
• Тип - зависящее от языка реализации описание типа параметра.
• Значение по умолчанию - значение параметра по умолчанию.

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

• Тип выражения, возвращающего значения - зависящее от языка реализации описание типа значения, возвращаемого функцией. Если оно не указано, то предполагается, что функция не возвращает значения (void для C/C++).

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

Операция, не изменяющая состояние системы, помечается следующим образом: в список свойств операции помещается свойство {query}.

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

"constructors"

CRect(CPoint left_up, CPoint right_down)

CRect(left:Integer, top:Integer, right:Integer, bottom:Integer)

"Data access"

GetLeftUp(): CPoint

SetLeftUp(CPoint lup)

GetRightDown():CPoint

SetRightDown (CPoint rdn)

...

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

"Get-Data functions"

GetLeftUp(): CPoint

SetLeftUp(CPoint lup)

"Set-Data functions"

GetRightDown():CPoint

SetRightDown (CPoint rdn)

...

У каждой секции прямоугольника класса может быть имя. При этом, так как секция "Имя класса" обязательна, то ее имя не указывается (рис.2.2).

4. Объект

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

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

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

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

display_window : WindowingSystem : : GraphicWindows : : Window

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

Вторая секция содержит в себе список имен атрибутов с их типами и значениями. Каждая строка из списка имеет синтаксис:

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

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

5. Составной объект

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

Составной объект представляется на диаграмме также как и просто объект. Имя объекта также располагается в верхней секции прямоугольника, а в нижней секции вместо атрибутов объекта располагаются части составного объекта (рис.2.4).

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

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

6. Активный объект

Активный объект (active object) имеет возможность инициировать действие. Пассивный объект может содержать в себе данные, но не может инициировать действия. Однако пассивный объект может посылать сообщения в процессе обработки запроса, который он получил.

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

7. Типы связей между классами

Ассоциация

Ассоциация (association) определяет некоторую связь между классами. Когда в системе создаются представители ассоциированных классов, они связываются так, как определяет данная ассоциация.

В UML одна ассоциация может специфицировать связь между двумя и несколькими (более чем двумя) классами. Ассоциации первого типа называются бинарными, а второго типа - N-арными.

• Бинарная ассоциация

Бинарная ассоциация (binary association) - это ассоциация между ровно двумя классами. Возможна ассоциация класса с самим собой, которая называется рефлексивной ассоциацией.

Изображается ассоциация в виде сплошной линии, соединяющей два символа класса. Каждая ассоциация обладает двумя ролями (association role), каждая роль представляет собой направление ассоциации. Большая часть информации, касающейся ассоциации, присоединена к ее ролям.

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

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

• Роль

Роль (association role) - это неотделимая часть ассоциации, описывающая некоторые свойства её соединения с классом (роль класса в данной ассоциации).

У роли могут быть следующие свойства:

• Имя роли - строка, стоящая рядом с концом ассоциации. Поле не обязательное, но если имя задано, оно должно отображаться на диаграмме.
• Навигация - если в направлении, соответствующем роли, поддерживается навигация, на конце линии может быть изображена стрелка. Возможность навигации в направлении роли означает, что партнеры ассоциации могут просматривать объекты, соответствующие этой роли.
• Множественность - показывает количество конкретных объектов, которые могут быть связаны с данным партнером ассоциации. В общем случае, множественность показывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в ассоциации.
• Квалификатор - представляет собой список атрибутов класса с противоположного конца ассоциации, по значениям которых можно однозначно разбить множество его объектов на подмножества. Используется для связи объекта класса-партнера ассоциации с группой объектов другого класса-партнера ассоциации.
• Агрегирование - показывает, что ассоциация является отношением типа целое/часть.

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

• Множественность

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

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

Пример:

0..1

10

0..*

3..5,10..20,100,200..*

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

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

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

Если у роли ассоциации установлен атрибут "aggregation", то вся ассоциация является отношением агрегирования. Такой атрибут может быть установлен только у одной из ролей.

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

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

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

Агрегирование изображается на диаграмме полым ромбом на конце линии ассоциации со стороны агрегирующего класса (агрегата) (рис.2.8). Композиция показывается также как и агрегирование, но ромбик рисуется не пустым, а заполненным.

Аналогично ключевому понятию модели классов - понятию ассоциации, - для объектов существует понятие связи (link).

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

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

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

• "association" - экземпляр ассоциации. Этот вид означает, что данная связь является экземпляром ассоциации, соединяющей соответствующие классы. Поскольку все связи есть экземпляры ассоциации, то указывать этот вид не имеет особого смысла, он выставляется по умолчанию.
• "parameter" - этот вид связи означает, что объект является параметром операции другого объекта-партнера связи.
• "local" - показывает, что объект есть локальный параметр операции или метода другого объекта-партнера связи.
• "global" - аналогично предыдущему, только здесь - глобальный параметр.
• "self" - применяется для обозначения связи объекта с самим собой. Используется, например, для обозначения возможности посылки объектом сообщений самому себе.

N-арная связь представляется на диаграмме как ромб от которого выходят соединения к объектам (рис.2.9). Остальные атрибуты N-арной связи такие же как и у бинарной связи.

9. Расширения понятия класса в UML

В UML существует несколько разновидностей класса: интерфейс, шаблон, утилита и др.

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

Шаблон (template) или параметризованный класс (parameterized class) - шаблоны UML очень похожи на шаблоны C++. Они определяют семейство классов, отличающихся значением некоторых формальных параметров;

Утилита (utility) - класс, объединяющий группу общедоступных (глобальных) переменных и процедур.

Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Интерфейс

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

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

На диаграмме классов UML интерфейс можно изобразить двумя способами: развернутым и сокращенным. В случае развернутого способа интерфейс изображается на диаграмме как класс со стереотипом "interface" и без секции атрибутов (рис.2.10). Допустимо также сокращенное изображение интерфейса - небольшой кружок с именем интерфейса возле него.

На рис. 2.10 изображен класс RunningLine, который реализует интерфейс DataConsumer. Связь между ними называется детализация и представляется на диаграмме в виде пунктирной линии с полым треугольником на конце. Таким образом, класс RunningLine должен предоставить метод, реализующий операцию SetData, унаследованную от интерфейса DataConsumer.

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

Параметризованные классы (шаблоны)

В некоторых случаях в модели необходимы классы со схожей структурой, которые отличаются некоторыми параметрами. Например, имеется описание нескольких динамических массивов для элементов разных типов, а многие операции над их элементами совпадают. Тогда было бы целесообразно определить такую структуру данных, чтобы с ее помощью было бы легко получить те самые динамические массивы, и делать это можно было бы уточнением параметров. Для этого в UML вводится понятие параметризованных классов (parameterized class), которые еще называют шаблонами (template).

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

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

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

На рис. 2.12 изображен шаблон TList (список, состоящий из k элементов типа C) и экземпляр этого шаблона RecordList, который получается подстановкой класса Record вместо формального параметра C, и присваиванием параметру k значения 30. На том же рисунке показано и сокращенное обозначение привязки конкретных значений формальным параметрам: TList<Rectangle, 6>. Здесь в угловых скобках по порядку перечислены фактические параметры: класс Rectangle и целое число 6.

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

Утилиты

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

На диаграмме утилита изображается как класс со стереотипом "utility", и может иметь как атрибуты, так и операции.

10. Зависимость

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

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

Существуют следующие виды зависимостей:

• Trace - показывает историческую связь между двумя элементами, которые представляли одно и то же понятие на разных этапах,
• Refine - историческая связь между элементами, как правило, показывает, что один элемент как бы произошел от другого,
• Uses - ситуация когда один элемент модели использует другой,
• Bind - устанавливается между шаблоном и экземпляром шаблона,
• Friend - аналог C++ friend.

Рисунок 2.13 "Зависимость элементов модели"

11. Наследование

Наследование (inheritance) - это отношение типа общее-частное между элементами модели.

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

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

На рис. 2.14 Geometry - это дискриминатор, а {disjoint} - его дополнительное свойство.

12. Множественное наследование

Во многих современных языках программирования множественное наследование запрещено. Связано это со следующей проблемой. Допустим, класс A наследуется от классов B и C, а классы B и C, в свою очередь, имеют общего предка D. Такая ситуация называется перекрывающимся наследованием. Неясно, какой из экземпляров D будет храниться в экземпляре A. Для решения этой проблемы была разработана концепция виртуального наследования, обеспечивающая единственность экземпляра класса D в памяти. Но ее использование небезопасно и нетривиально.

Для того чтобы уточнить подробности, касающиеся множественного наследования, на дискриминатор могут накладываться дополнительные ограничения (constraint):

• disjoint - запрещение множественного наследования,
• overlapping - разрешение множественного наследования.

В контексте рисунка 2.14 первое свойство означает, что нельзя в множественном наследовании использовать двух потомков класса figure, если они произведены от него через ветку наследования, помеченную дискриминатором geometry. Если бы этот дискриминатор имел свойство {overlapping}, то это было бы возможно. По умолчанию дискриминатор имеет свойство {overlapping}.

Для дискриминатора можно указать дополнительные ограничения, не касающиеся множественного наследования:

• complete - все потомки рассматриваемого класса определены (возможно, не показаны на данной диаграмме), и список потомков не может быть расширен (рис.2.15),
• incomplete - возможно появление новых классов-потомков.

В контексте диаграмм классов, пакет (package) - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен.

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

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

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

На рис. 2.16 показано, что пакет с именем Current импортирует пакет с именем Java::awt.

В начало
Вернуться на страницу <Model Vision Studium>