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

Цель работы:

  • изучение диаграмм классов,
  • изучение их применения в процессе проектирования.

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

Кнопка Описание Название

p11-1.jpg (3869 bytes)

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

 

Упражнение 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 и нажмите на кнопку ОК .
  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.

11-4.jpg (20628 bytes)

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

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

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

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

Упражнение 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.

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

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

11-5-1.jpg (23544 bytes) 11-5.jpg (38126 bytes)

Вид диаграммы в 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.
  1. Каково назначение диаграмм классов?
  2. Для чего используется диаграмма классов на стадии анализа?
  3. Для чего используется диаграмма классов на стадии проектирования?
  4. Назовите основные компоненты диаграмм классов.
  5. Назовите основные типы статических связей между классами.
  6. Что представляет собой ассоциация?
  7. В чем смысл множественности ассоциаций?
  8. В чем отличие атрибутов от ассоциаций?
  9. Что такое признак видимости?
  10. Что представляет собой операция класса?
  11. В чем смысл обобщения?
  12. Каково назначение ограничений на диаграммах классов?