УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML

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

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

3.5).

ClassName

+attribute

-privateAttr

-fio:String=”Novikov”

-array:char[10]

+operationName()

-staticOperation() +function():int

Рис. Ошибка! Текст указанного стиля в документе отсутствует..27. Типичная нотация класса

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

Секция имени класса в общем случае имеет следующий синтаксис.

«стереотип» ИМЯ {свойства} кратность

Имени класса может предшествовать стереотип. В таблице 3.2 перечислены стандартные стереотипы классов.

Таблица Ошибка! Текст указанного стиля в документе отсутствует..5. Стандартные стереотипы классов

91

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

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

3.2.2. Атрибуты

Атрибут — это именованное место (или, как говорят, слот), в котором может храниться значение.

Атрибуты класса перечисляются в секции атрибутов. В общем случае описание атрибута имеет следующий синтаксис.

видимость ИМЯ кратность : тип = начальное_значение {свойства}

Видимость, как обычно, обозначается знаками +, –, #, ~. Еще раз подчеркнем, что если видимость не указана, то никакого значения видимости по умолчанию не подразумевается.

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

Кратность, если она присутствует, определяет данный атрибут как массив (определенной или неопределенной длины).

Тип атрибута — это либо примитивный (встроенный) тип, либо тип, определенный пользователем.

92

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

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

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

Таблица Ошибка! Текст указанного стиля в документе отсутствует..6. Примеры описаний атрибутов

93

3.2.3. Операции и методы

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

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

Метод — это реализация операции, т.е. выполняемый алгоритм.

Выполнение действий, определяемых операцией, инициируется

вызовом метода.

При вызове метода могут, в свою очередь, быть вызваны методы этого же, а также других классов.

Описания операций класса перечисляются в секции операций и имеют следующий синтаксис.

видимость ИМЯ (параметры) : тип {свойства}

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

направление ПАРАМЕТР : тип = значение

Начнем по порядку. Видимость, как обычно, обозначается с помощью знаков +, –, #, ~ или с помощью ключевых слов private, public, protected, package. Подчеркивание имени означает, что область действия операции — класс, а не объект. Например, конструкторы имеют область действия класс. Курсивное написание имени означает, что операция абстрактная, т. е. в данном классе ее реализация не задана и должна быть задана в подклассах данного класса. После имени в скобках может быть указан список описаний параметров. Описания параметров в списке разделяются запятой. Для каждого параметра обязательно указывается имя, а также могут быть

94

указаны направление передачи параметра, его тип и значение аргумента по умолчанию.

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

Таблица Ошибка! Текст указанного стиля в документе отсутствует..7. Ключевые слова для описания направления передачи параметров

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

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

Рассмотрим примеры описания возможных операций класса Person информационной системы отдела кадров в таблице 3.5.

Таблица Ошибка! Текст указанного стиля в документе отсутствует..8. Примеры описания операций

95

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

3.2.4. Интерфейсы и типы данных

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

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

Другими словами, интерфейс — это абстрактный класс, в котором все составляющие — атрибуты и операции — абстрактны.

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

Следующая тема для обсуждения — типы данных.

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

Вмодели UML можно использовать три вида типов данных. Примитивные типы (PrimitiveType), которые считаются

предопределенными в UML. Таковыми являются следующие:

96

целочисленный тип (Integer), булевский тип (Boolean), строковый тип (String). Существует еще один дополнительный тип, который описывает множество (может быть бесконечное) натуральных чисел (UnlimitedNatural). Используется этот тип в основном для указания кратности той или иной сущности. Инструменты вправе расширять этот набор и использовать другие подходящие названия.

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

Типы данных, которые определены в модели пользователем.

Данные типы представляются в виде классификаторов со стереотипом

«enumeration» или «dataType».

Особого внимания заслуживает перечислимый тип данных (enumeration). Например, тип Boolean определен в UML как перечислимый тип со значениями true и false. Если в проектируемом приложении нужно использовать не обычную двузначную логику, а трехзначную, то тогда соответствующий тип можно определить так, как показано на рис. ошибка! текст указанного стиля в документе отсутствует..28.

«enumeration» 3Logic

yes no

unknown

+add(a:3Logic, b:3Logic) +or(a:3Logic, b:3Logic)

Рис. Ошибка! Текст указанного стиля в документе отсутствует..28. Перечислимый тип данных «Трехзначная логика»

97

3.3. ОТНОШЕНИЯ НА ДИАГРАММЕ КЛАССОВ

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

иобобщения. Отношения зависимости и реализации на диаграммах классов применяются реже, но, тем не менее, они также применяются,

имы начнем с них, как с более простых.

3.3.1. Отношения зависимости и реализации

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

-между классами и объектами на диаграмме классов;

-между пакетами;

-между вариантами использования;

-другие.

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

Таблица Ошибка! Текст указанного стиля в документе отсутствует..9. Стандартные стереотипы зависимостей на диаграмме классов

98

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

-классификатор (в частности, класс) использует интерфейс — это показывается с помощью зависимости со стереотипом «call»;

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

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

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

99

интерфейс IPosition и связать его отношениями с данными классами.

«interface»

IPosition Position

+occupy(Person)

+free()

+position:IPosition

«call»

Department

Рис. Ошибка! Текст указанного стиля в документе отсутствует..29 Отношения реализации и использования интерфейсов

3.3.2. Отношение обобщения

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

Таким образом, сокращается суммарное количество описаний, а значит, уменьшается вероятность допустить ошибку. Использование обобщений не ограничивает свободу проектировщика системы, поскольку унаследованные составляющие можно переопределить в подклассе. Для указания того, что та или иная составляющая переопределена в подклассе следует использовать появившееся в UML 2 дополнение redefines (см. рис. ошибка! текст указанного стиля в документе отсутствует..30) .

По умолчанию обобщения являются подстановочными (substitutable), т.е. удовлетворяют принципу подстановки. Рассмотрим пример.

100