Диаграммы классов

Оглавление
Диаграммы классов
Ассоциации
Атрибуты
Операции
Ограничения
Упражнения
Анализ вариантов использования
Добавление атрибутов
Добавление связей
Создание ассоциаций
Создание агрегаций
Создание обобщений
Контрольные вопросы
Все страницы

Диаграммы классов

Цель работы:

изучение диаграмм классов,

изучение их применения в процессе проектирования.

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

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

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

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

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

ассоциации (например, менеджер может вести несколько проектов),

подтипы (работник является разновидностью личности).

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

Ассоциации

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

11-1.jpg (22842 bytes)

Рис. 11.1. Типичная диаграмма классов

Любая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между «Исполнителем» и «Отчетом» содержит две роли: одна от «Исполнителя» к «Отчету»; другая - от «Отчета» к «Исполнителю». Роль может быть явно поименована с помощью метки. Если такая метка отсутствует, роли присваивается имя класса-цели; таким образом, роль ассоциации от «Исполнителя» к «Отчету» может быть названа «Отчетом».

Роль также обладает множественностью, которая показывает, сколько объектов может участвовать в данной связи. На рис. 11.1 символ «0..*» над ассоциацией между «Менеджером» и «Контрактом» показывает, что с одним «Менеджером» может быть связано много «Контрактов»; символ «1» показывает, что любой «Контракт» управляется одним «Менеджером».

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

Для ассоциации может быть указано направление навигации. Если навигация указана только в одном направлении, то такая ассоциация называется однонаправленной (ассоциация между «Менеджером» и «Отчетом» на рис. 11.1). У двунаправленной ассоциации навигация указана в обоих направлениях. В языке UML отсутствие стрелок у ассоциации трактуется следующим образом: направление навигации неизвестно или ассоциация является двунаправленной.

Атрибуты

Атрибуты во многом подобны ассоциациям. Разница между ними заключается в том, что атрибуты предполагают единственное направление навигации - от типа к атрибуту.

На рис. 11.1 атрибуты указаны для классов «Контракт» и «Отчет». В зависимости от степени детализации диаграммы, обозначение атрибута может включать имя атрибута, тип и значение, присваиваемое по умолчанию. В синтаксисе UML это выглядит следующим образом: <признак видимости> <имя> : <тип> = <значение по умолчанию>, где признак видимости может принимать одно из следующих четырех значений:

общий

(public) -

атрибут доступен для всех клиентов класса,

защищенный

(protected) -

атрибут доступен только для подклассов
и друзей класса,

секретный

(private) -

атрибут доступен только для друзей класса,

реализация

(implementation) -

атрибут доступен только внутри об
рамляющего пакета.

Операции

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

Полный синтаксис UML для операций выглядит следующим образом: <признак видимости> <имя> (<список-параметров>): <тип-выражения-возвращающего-значение> = <строка-свойств>, где

признак видимости может принимать те же значения, что и для атрибутов;

имя представляет собой символьную строку;

список-параметров содержит необязательные аргументы, синтаксис которых совпадает с синтаксисом атрибутов;

тип-выражения-возвращающего-значение является необязательной спецификацией и зависит от конкретного языка программирования;

строка-свойств показывает значения свойств, которые применяются к данной операции. Примером операции на рис. 11.1 является операция закрыть() класса «Контракт».

Обобщение

Типичный пример обобщения включает «Команду проекта» и «Субподрядчика» (см. рис. 11.1). Они обладают некоторыми различиями, однако

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

Смысл обобщения заключается в том, что интерфейс подтипа должен включать все элементы интерфейса супертипа. Другая сторона обобщения связана с принципом подстановочности. Субподрядчика можно подставить в любой код, где требуется «Исполнитель», и при этом все должно нормально работать. Это означает, что, разработав код, предполагающий использование «Исполнителя», можно свободно употреблять экземпляр любого подтипа «Исполнителя». Субподрядчик может реагировать на некоторые команды отличным от другого «Исполнителя образом» (в соответствии с принципом полиморфизма), но это отличие не должно беспокоить вызывающий объект.

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

Ограничения

При постройке диаграмм классов основным занятием является отображение различных ограничений. На рис. 11.1 показано, что «Контракт» может управляться только одним «Менеджером».

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

В UML отсутствует строгий синтаксис описания ограничений, за исключением помещения их в фигурные скобки {}.

Таблица 11.1. Описание кнопок панели инструментов диаграмм классов Rational Rose

Кнопка	Описание	Название
	Выбор элемента модели	Sekection Tool
	Ввод текста	Text Box
	Комментарий	Note
	Связь комментария с элементом	Abchor Note to Item
	Класс	Class
	Интерфейс	Interfase
	Ассоциация	Association
	Агрегация	Aggrigation
	Привязка атрибута	Link Attribyte
	Добавление пакета	Packege
	Зависимость	Dependency
	Наследование	Generalization
	Реализация	Realize

3. Упражнения

Упражнение 1. Создание структуры модели и классов анализа в соответствии с требованиями архитектурного анализа

Создание пакетов и диаграммы Traceabilities:
1. Щелкните правой кнопкой мыши по логическому представлению браузера.
2. Выберите пункт New > Package в открывшемся меню.
3. Назовите новый пакет Design Model.
4. Создайте аналогичным образом пакеты Use-Case Realizations,Use-Case Realization- Close Registration, Use-Case
Realization - Login и Use-Case Realization - Register for Courses в соответствии с рис. 11.2.

11-22.jpg (17881 bytes)

Рис. 11.2 Создание классов анализа и соответствующей диаграммы Key Abstractions:

1. Щелкните правой кнопкой мыши по пакету Design Model.
2. Выберите пункт New > Class в открывшемся меню. Новый класс под названием NewClass появится в браузере.
3. Выделите его и введите имя Student.
4. Создайте аналогичным образом классы Professor, Schedule, Course и CourseOffermg.
5. Щелкните правой кнопкой мыши по пакету Design Model
6. Выберите пункт New > Class Diagram в открывшемся меню.
7. Назовите новую диаграмму классов Key Abstractions.
8. Чтобы расположить вновь созданные классы на диаграмме классов, откройте ее и перетащите классы на открытую диаграмму мышью. Диаграмма классов должна выглядеть, как на рис. 11.3

11-3.jpg (8196 bytes)

Рис 11.3 Диаграмма классов

Анализ вариантов использования

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

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

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

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

Пример набора классов, участвующих в реализации варианта использования Register for Courses, приведен на рис. 11.4.

Упражнение 2. Создание классов, участвующих в реализации варианта использования Register for Courses, и диаграммы классов «View Of Participating Classes» (VOPC)

1. Щелкните правой кнопкой мыши по пакету Design Model.
2. Выберите пункт New > Class в открывшемся меню. Новый класс под названием NewClass появится в браузере.
3. Выделите его и введите имя RegisterForCoursesForm.
4. Щелкните правой кнопкой мыши, по классу RegisterFor CoursesForm..
5. Выберите пункт Open Specification в открывшемся меню.
6. В поле стереотипа введите Boundary и нажмите на кнопку ОК .

11-4.jpg (20628 bytes)

Рис. 11.4 Классы, участвующие в реализации варианта использования Register for Courses

7. Создайте аналогичным образом классы CourseCatalogSystem со стереотипом Boundary и RegistrationControIler со стереотипом Control.
8. Назначьте классам Schedule, CourseOffering и Student стереотип Entity
9. Щелкните правой кнопкой мыши в пакете Use-Case Realization - Register for Courses.
10.Выберите пункт New > Class Diagram в открывшемся меню.
11.Назовите новую диаграмму классов VOPC (classes only).
12.Откройте ее и перетащите классы на открытую диаграмму в соответствии с рис. 11.4.

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

• обработка ошибок
• контроль времени выполнения;
• обработка неправильных вводимых данных.

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

Упражнение 3. Добавление атрибутов к классам

1. В меню модели выберите пункт Tools > Options.
2. Перейдите на вкладку Diagram.
3. Убедитесь, что переключатель Show All Attributes помечен.
4.Убедитесь, что переключатели Suppress Attributes и Suppress Operations не помечены.

Добавление атрибутов
1. Щелкните правой кнопкой мыши по классу Student.
2. Выберите пункт New Attribute в открывшемся меню.
3. Введите новый атрибут address.
4. Нажмите клавишу Enter.
5. Повторите шаги 1 - 4, добавив атрибуты name и studentlD.
6.Добавьте атрибуты к классам CourseOffering, Shedule и PrimaryScheduleOfferinglnfo.

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

Упражнение 4. Добавление связей

Добавим связи к классам, принимающим участие в варианте использования Register for Courses. Для отображения связей между классами построим три новые диаграммы классов в кооперации Register for Courses пакета Use-Case Realization - Register for Courses (рис. 11.5 - 11.7). Добавлены два новых класса - подклассы FulltimeStudent (Студент очного отделения) и ParttimeStudent (Студент вечернего отделения).


Вид диаграммы в Rational Rose 98	Вид диаграммы в Rational Rose 2001

Рис. 11.5 Диаграмма Entity Classes (классы-сущности)

На данной диаграмме показаны классы ассоциаций, описывающие связи между классами Schedule и CourseOffering, и добавлен суперкласс ScheduleOfferinglnfo. Данные и операции, содержащиеся в этом классе (status - курс включен в график или отменен), относятся как к основным, так и к альтернативным курсам, в то время как оценка (grade) и окончательное включение курса в график могут иметь место только для основных курсов.

Создание ассоциаций
Ассоциации создают непосредственно на диаграмме классов. Панель инструментов диаграммы классов содержит кнопки для создания как одно-, так и двунаправленных ассоциаций. Для создания на диаграмме классов ассоциации сделайте следующее:
1. Нажмите на панели инструментов кнопку Association.
2. Проведите мышью линию ассоциации от одного класса к другому.

11-6.jpg (39369 bytes)

Рис. 11.6. Диаграмма CourseOfferinglnfo

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

Для того чтобы создать рефлексивную ассоциацию:
1.На панели инструментов диаграммы нажмите кнопку Association.
2.Проведите линию ассоциации от класса до какого-нибудь места вне класса.
3.Отпустите кнопку мыши.
4.Проведите линию ассоциации назад к классу.

11-7.jpg (45847 bytes)

Рис. 11.7. Полная диаграмма классов VOPC (без атрибутов и операций)

Создание агрегаций
1. Нажмите кнопку Aggregation панели инструментов.
2. Проведите линию агрегации от класса-части к целому.

Для того чтобы поместить на диаграмму классов рефлексивную агрегацию:
1. На панели инструментов диаграммы нажмите кнопку Aggregation.
2. Проведите линию агрегации от класса до какого-нибудь места вне класса.
3. Отпустите кнопку мыши.
4. Проведите линию агрегации назад к классу.

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

Чтобы поместить обобщение на диаграмму классов:
1. Нажмите кнопку Generalization панели инструментов.
2.Проведите линию обобщения от подкласса к суперклассу.

Спецификации связей
Спецификации связей касаются имен ассоциаций, ролевых имен, множественности и классов ассоциаций. Для того чтобы задать множественность связи:
1. Щелкните правой кнопкой мыши на одном конце связи.
2. Выберите пункт Multiplicity в открывшемся меню.
3. Укажите нужную множественность.
4. Повторите то же самое для другого конца связи.

Для того чтобы задать имя связи:
1.Выделите нужную связь.
2.Введите ее имя.

Для того чтобы задать связи ролевое имя:
1.Щелкните правой кнопкой мыши на ассоциации с нужного конца.
2.Выберите пункт role Name в открывшемся меню.
3. Введите ролевое имя.

Для того чтобы задать элемент связи (класс ассоциаций):
1.Откройте окно спецификации требуемой связи.
2.Перейдите на вкладку Detail.
3.Задайте элемент связи в поле Link Element.