Добавление класса на диаграмму классов и редактирование его свойств
Лабораторная работа №10
Тема. Построение диаграмм классов в среде Rational Rose
Цель работы: изучение инструментария программного средства Rational Rose, формирование умений построения диаграмм классов и редактирование свойств ее элементов.
Задачи работы:
изучить инструментарий программного средства Rational Rose;
освоить приемы построения диаграмм;
построить диаграмму классов.
ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.
Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.
Классы
Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).
|
|
|
Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов или одной диаграммой. Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные без пробелов. Имена классов образуют словарь предметной области.
Например, класс “Стена” описывает объекты с общими свойствами: высотой, длиной, толщиной, и т.д.
При этом конкретные стены будут рассматриваться как отдельные экземпляры
класса «стена». У каждого класса есть имя, (простое или составное, к которому
спереди добавлено имя пакета, в который входит класс). Имя класса в пакете
должно быть уникальным. Класс реализует один или несколько интерфейсов.
Рис. 40 Простые и составные имена
|
|
|
Если необходимо явно указать к какому пакету относится тот или иной класс, то используется символ разделитель двойное двоеточие «::». Синтаксис строки имени класса в этом случае будет следующий: <Имя_пакета>::<Имя_класса>. Например, если определен пакет с именем «Банк», то класс «Счет» в этом банке может быть записан в виде: «Банк::Счет».
Атрибуты класса или свойства записываются во второй сверху секции прямоугольника класса.
В языках высокого уровня, таких, как С++, Java, атрибуты соответствуют переменным, объявленным в классе. Например, у любой стены есть высота, ширина и толщина. Атрибуты представлены в разделе, расположенном под именем класса;
при этом указываются их имена, и иногда начальное значение (рис. 41).
В языке UML каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения:
<квантор видимости><имя атрибута>[кратность]:
<тип атрибута> = <исходное значение>{строка-свойство}
Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:
|
|
|
«+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;
«#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;
«-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.
Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения атрибута.
Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста в квадратных скобках после имени соответствующего атрибута:
[нижняя_граница1 .. верхняя_граница1, нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak .. верхняя_границаk],
где нижняя граница и верхняя граница являются положительными целыми числами, каждая пара которых служит для обозначения отдельного замкнутого интервала целых чисел. В качестве верхней границы может использоваться специальный символ «*», который означает произвольное положительное целое число.
|
|
|
Операции или методы класса записываются в третьей сверху секции прямоугольника. Операция (operation) представляет собой некоторый сервис, предоставляемый каждым экземпляром класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции:
<квантор видимости><имя операции>(список параметров):
<выражение типа возвращаемого значения>{строка-свойство}
Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и отображается соответствующими символами:
«+» обозначает операцию с областью видимости типа общедоступный (public);
«#» обозначает операцию с областью видимости типа защищенный (protected);
«-» используется для обозначения операции с областью видимости типа закрытый (private).
При изображении класса необязательно сразу показывать все его атрибуты
и операции. Их может быть много, однако для данного представления системы
лишь небольшое подмножество атрибутов и операций имеет значение. В это
случае класс сворачивают, и изображают только некоторые из атрибутов и
операций, а дополнительные атрибуты или операции обозначают многоточием.
Для лучшей организации списков атрибутов и операций можно снабдить каждую
группу дополнительным описанием (стереотипами).
Обязанности класса – это своего рода контракт, которому он должен
подчиняться. Атрибуты и операции являются свойствами, посредством которых
выполняются обязанности класса. Например, класс FraudAgent (агент по
предотвращению мошенничества), который встречается в приложениях по
обработке кредитных карточек, отвечает за оценку платежных требований –
законные, подозрительные или подложные (рис. 43). Моделирование классов
лучше всего начинать с определения обязанностей сущностей, которые входят в словарь системы. Число обязанностей класса может быть произвольным, но на практике хорошо структурированный класс имеет по меньшей мере одну
обязанность; с другой стороны, их не должно быть и слишком много. При
уточнении модели обязанности класса преобразуются в совокупность атрибутов и операций, которые должны наилучшим образом обеспечить их выполнение.
Рис. 43 Обязанности
Отношения между классами
Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями в языке UML являются:
зависимости (dependency relationship);
ассоциации (association relationship);(агрегации и композиции)
обобщения (generalization relationship)
реализации (realization relationship)
Каждое из этих отношений имеет собственное графическое представление на диаграмме, которое отражает взаимосвязи между объектами соответствующих классов.
Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Оно используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой, направленной от класса-клиента зависимости к независимому классу или классу-источнику.
В качестве класса-клиента и класса-источника зависимости могут выступать целые множества элементов модели. В этом случае одна линия со стрелкой, выходящая от источника зависимости, разделяется в некоторой точке на несколько линий, каждая из которых имеет отдельную стрелку для класса-клиента.
Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения. Если оно задано, то записывается с заглавной (большой) буквы рядом с линией соответствующей ассоциации.
Специальной формой или частным случаем отношения ассоциации является отношение агрегации, которое, в свою очередь, тоже имеет специальную форму - отношение композиции.
Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности.
В качестве примера отношения агрегации рассмотрим взаимосвязь типа "часть-целое", которая имеет место между сущностью "Грузовой автомобиль" и такими компонентами, как "Двигатель", "Шасси", "Кабина", "Кузов". Не претендуя на точное соответствие терминологии данной предметной области, нетрудно представить себе, что грузовой автомобиль состоит из двигателя, шасси, кабины и кузова. Именно это отношение между классом "Грузовой_автомобиль" и классами "Двигатель", "Шасси", "Кабина", "Кузов" описывает отношение агрегации.
Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 6.2.8).
Рисунок 6.2.8. Графическое изображение отношения агрегации в языке UML
Еще одним примером отношения агрегации может служить деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя обозначения языка UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (рис. 6.2.9), которая в данном случае иллюстрирует отношение агрегации.
Рисунок 6.2.9. Диаграмма классов для иллюстрации отношения агрегации на примере ПК
Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения «часть-целое», при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, то есть с уничтожением целого уничтожаются и все его составные части.
Пример этого отношения представляет собой живая клетка в биологии. Другой пример - окно интерфейса программы, которое может состоять из строки заголовка, кнопок управления размером, полос прокрутки, главного меню, рабочей области и строки состояния. Подобное окно представляет собой класс, а его компоненты являются как классами, так и атрибутами или свойствами окна.
Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или "целое". Остальные классы являются его "частями" (рис. 6.2.10).
Рисунок 6.2.10. Графическое изображение отношения композиции в языке UML
В качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться указание кратности класса ассоциации и имени данной ассоциации, которые не являются обязательными. Применительно к описанному выше примеру класса "Окно_программы" его диаграмма классов может иметь следующий вид (рис. 6.2.11).
Рисунок 6.2.11. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы
Отношение обобщения является обычным таксономическим отношением между более общим элементом (предком) и более частным или специальным элементом (потомком). Данное отношение может использоваться для представления взаимосвязей между пакетами, классами, вариантами использования и другими элементами языка UML.
Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов. Стрелка указывает на общий класс (класс-предок или суперкласс), а ее отсутствие - на специальный класс (класс-потомок или подкласс).
Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 6.2.12). Стрелка указывает на более общий класс (класс-предок или суперкласс), а ее отсутствие - на более специальный класс (класс-потомок или подкласс).
Рисунок 6.2.12. Графическое изображение отношения обобщения в языке UML
Более общий класс разбивается на подклассы одним отношением обобщения. Например, класс Геометрическая_фигура_на_плоскости (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным геометрическим фигурам, таким как, Прямоугольник, Окружность, Эллипс и др. Данный факт может быть представлен графически в форме диаграммы классов следующего вида (рис. 6.2.13).
Рисунок 6.2.13. Пример графического изображения отношения обобщения классов
С целью упрощения обозначений на диаграмме классов совокупность линий, обозначающих одно и то же отношение обобщения, может быть объединена в одну линию, как показано на рисунке 6.2.14.
Рис. 6.2.14. Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий
Отношение реализации (реализация, realization) возникает между классами в том случае, когда один класс задает требования к поведению системы (функциональную спецификацию), а другой является полной или частичной программной или аппаратной реализацией этого поведения. Примерами классов, задающих спецификации поведения, являются варианты использования. Кроме того, в UML определены специальные классы - интерфейсы, предназначенные для отдельного перечисления множества видимых операций одного или совокупности других классов без указания деталей реализации. Поскольку одна и та же спецификация может быть реализована многими способами, а реализация может относиться к нескольким спецификациям, то множественность этой связи М:N («многие ко многим»). Тот, кто реализует, называется клиентом, а носитель спецификации называется источником (поставщиком). Клиент не наследует операции источника, он их определяет вновь или наследует от своего предка, однако для полноты должны быть объявлены все операции источника. Отношение реализации изображается пунктирной стрелкой с незакрашенным треугольным наконечником, идущей от реализации к спецификации (от клиента к поставщику). В реализацию могут быть добавлены дополнительные операции (по сравнению со спецификацией), если они способствуют выполнению основных операций.
Интерфейсы
Интерфейсы являются элементами диаграммы вариантов использования. Однако, при построении диаграммы классов, отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ - прямоугольник класса с ключевым словом или стереотипом «interface». При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.
Объекты
Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. В силу самых различных причин может возникнуть необходимость показать взаимосвязи не только между классами модели, но и между отдельными объектами, реализующими эти классы. В таком случае может быть разработана диаграмма объектов, которая, хотя и не является канонической в метамодели языка UML, но имеет самостоятельное назначение.
Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые обязательно подчеркиваются. При этом запись имени объекта представляет собой строку текста «имя объекта:имя класса», разделенную двоеточием. Имя объекта может отсутствовать. В этом случае предполагается, что объект является анонимным. Отсутствовать может и имя класса. Тогда указывается просто имя объекта. Атрибуты объектов имеют конкретные значения.
При изображении диаграммы объектов нужно помнить, что каждый объект представляет собой экземпляр соответствующего класса, а отношения между объектами описываются с помощью связей (links), которые являются экземплярами соответствующих отношений. При этом все связи изображаются сплошными линиями.
Мощность отношений
Мощность отношения (мулитипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в ее конце. Различают следующие типичные случаи :
| нотация | объяснение | пример |
| 0..1 | Ноль или один экземпляр | кошка имеет или не имеет хозяина |
| 1 | Обязательно один экземпляр | у кошки одна мать |
| 0..* или * | Ноль или более экземпляров | у кошки может быть, а может и не быть котят |
| 1..* | Один или более экземпляров | у кошки есть хотя бы одно место, где она спит |
Примеры диаграммы классов
На рис. 51 показана совокупность классов, взятых из информационной
системы вуза. Этот рисунок содержит достаточное количество деталей для
конструирования физической базы данных. В нижней части диаграммы
расположены классы Студент, Курс и Преподаватель. Между классами Студент
и Курс есть ассоциация, показывающая, что студенты могут посещать курсы.
Более того, каждый студент может посещать любое количество курсов и на
каждый курс может записаться любое число студентов.
Два класса (Вуз и Факультет) содержат несколько операций, позволяющих
манипулировать их частями. Эти операции включены из-за их важности для
поддержания целостности данных (например, добавление или удаление
Факультета затрагивает целый ряд других объектов).
Существует много других операций, которые стоило бы рассмотреть при
проектировании этих и иных классов, например запрос о необходимых
предварительных знаниях перед зачислением студента на курс. Но это, скорее,
бизнес-правила, а не операции по поддержанию целостности данных, поэтому
лучше располагать их на более высоком уровне абстракции.
На рис. 52 представлен пример диаграммы классов структуры компании.
Рис. 52 Диаграмма классов
ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Вы являетесь руководителем библиотеки. Библиотека зарабатывает деньги, выдавая напрокат некоторые книги, имеющиеся в небольшом количестве экземпляров.
У каждой книги, выдаваемой в прокат, есть название, автор, жанр.
В зависимости от ценности книги вы определили для каждой из них залоговую стоимость (сумма, вносимая клиентом при взятии книги напрокат) и стоимость проката (сумма, которую клиент платит при возврате книги, получая назад залог). В библиотеку обращаются читатели. Все читатели регистрируются в картотеке, которая содержит стандартные анкетные данные (фамилия, имя, отчество, адрес, телефон). Каждый читатель может обращаться в библиотеку несколько раз. Все обращения читателей фиксируются, при этом по каждому факту выдачи книги запоминаются дата выдачи и ожидаемая дата возврата.
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы. Активизировать рабочее окно диаграммы классов можно несколькими способами:
окно диаграммы классов появляется по умолчанию в рабочем окне диаграммы после создания нового проекта;
щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов;
раскрыть логическое представление (Logical View) в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная);
выполнить операцию главного меню: Browse>Class Diagram (Обзор>Диаграмма классов).
При этом появляется новое окно с чистым рабочим листом диаграммы классов и специальная панель инструментов, содержащая кнопки с изображением графических примитивов, необходимых для разработки диаграммы классов. Назначение отдельных кнопок панели можно узнать также из всплывающих подсказок.
На специальной панели инструментов по умолчанию присутствует только часть пиктограмм элементов, которые могут быть использованы для построения диаграммы классов. Добавить кнопки с пиктограммами других графических элементов таких как, например, отношения агрегации и композиции, шаблон, класс бизнес-сущность, управляющий класс, или удалить ненужные кнопки можно с помощью настройки специальной панели инструментов. Соответствующее диалоговое окно настройки специальной панели инструментов для диаграммы классов можно вызвать аналогично другим панелям с помощью операции контекстного меню Customize (Настройка) при позиционировании курсора на специальной панели инструментов.
Добавление класса на диаграмму классов и редактирование его свойств
Для добавления класса на диаграмму классов нужно с помощью левой кнопки мыши нажать кнопку с изображением пиктограммы класса на специальной панели инструментов, отпустить левую кнопку мыши и щелкнуть левой кнопкой мыши на свободном месте рабочего листа диаграммы. На диаграмме появится изображение класса с маркерами изменения его геометрических размеров и предложенным средой именем по умолчанию NewClass.
Продолжая разработку модели библиотеки в качестве сквозного примера проекта, построим для этой модели следующую каноническую диаграмму - диаграмму классов. С этой целью следует изменить предложенное по умолчанию имя диаграммы Main на Диаграмма классов, а имя добавленного на диаграмму класса - на Книга. Графическое представление приведено на рисунке 1.
Рисунок 1.Диаграмма классов модели библиотеки после добавления на нее класса Книга
Поскольку разрабатываемая модель библиотеки на начальных этапах работы над проектом используется для анализа общей архитектуры проекта и согласования ее с различными участниками рабочей группы, имена классов, их атрибутов и операций для большей наглядности и понимания задаются на русском языке с пробелами и записываются символами кириллицы. В последующем по мере выполнения проекта и реализации модели на некотором языке программирования, имена соответствующих классов, атрибутов и операций должны быть преобразованы в символы латиницы. При этом имена этих элементов модели должны быть записаны без пробелов. В контексте управляемой моделью архитектуры первую модель еще называют независимой от платформы реализации, а вторую - зависимой от платформы реализации.
Дата добавления: 2021-07-19; просмотров: 103; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!