Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Отношение ассоциации

Отношения между классами

Области видимости и действия, кратность и иерархия классов

Классы

Примеры диаграмм деятельностей

 

Пример: Диаграмма описания алгоритма функции «Модификация данных»

Рис. 6.75. Модификация данных

 

 

Пример: Диаграмма описания алгоритма функции «Удалить запись»

Рис. 6.76. Удалить запись

 

 

 

Классы – это самые важные строительные блоки любой объектно–ориентированной системы.

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

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

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

Графическое изображение класса в UML показано на рис. 6.77. Такое обозначение абстракции независимо от конкретного языка программирования и подчеркивает ее наиболее важные характеристики: имя, атрибуты и операции.

 

Рис. 6.77. Классы

 

У каждого класса есть имя, отличающее его от других классов. Имя класса – это текстовая строка. Взятое само по себе, оно называется простым именем. К составному имени впереди добавлено имя пакета, в который входит класс. Имя класса в объемлющем пакете должно быть уникальным. Например, java::awt::Rectangle. Имя класса может состоять из любого числа букв, цифр и ряда знаков препинания (за исключением таких, например, как двоеточие, которое применяется для отделения имени класса от имени объемлющего пакета). Имя может занимать несколько строк. На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы. Обычно каждое слово в имени класса пишется с заглавной буквы, например: Customer (Клиент).

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

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

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

 

Рис. 6.78. Атрибуты и их класс

 

Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция – это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе. Часто (хотя не всегда) обращение к операции объекта изменяет его состояние или его данные. Операции класса изображаются в разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только именами, как показано на рис. 6.79. Имя операции, как и имя класса, может быть произвольной текстовой строкой. На практике для именования операций используют короткий глагол или глагольный оборот, соответствующий определенному поведению объемлющего класса. Каждое слово в имени операции, кроме самого первого, обычно пишут с заглавной буквы, например move или isEmpty.

 

Рис. 6.79. Операции

 

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

 

Рис. 6.80. Операции и их сигнатуры

 

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

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

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

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

Графически обязанности изображают в особом разделе в нижней части пиктограммы класса (рис. 6.81.). Их можно указать также в примечании.

 

Рис. 6.81. Обязанности

 

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

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

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

Хорошо структурированный класс обладает следующими свойствами:

является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения;

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

поддерживает четкое разделение спецификаций абстракции и ее реализации;

понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.

 

 

 

Одна из деталей, наиболее существенных для атрибутов и операций классификаторов, – их видимость. Видимость свойства говорит о том, может ли оно использоваться другими классификаторами. Естественно, это подразумевает видимость самого классификатора. Один классификатор может "видеть" другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML можно определить три уровня видимости:

public (открытый) – любой внешний классификатор, который "видит" данный, может пользоваться его открытыми свойствами. Обозначается знаком + (плюс) перед именем атрибута или операции;

protected (защищенный) – любой потомок данного классификатора может пользоваться его защищенными свойствами. Обозначается знаком # (диез);

private (закрытый) – только данный классификатор может пользоваться закрытыми свойствами. Обозначается символом – (минус).

На рис. 6.82. показаны открытые, защищенные и закрытые атрибуты и методы для класса Toolbar.

 

Рис. 6.82. Видимость

 

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

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

instance (экземпляр) – у каждого экземпляра классификатора есть собственное значение данного свойства;

classifier (классификатор) – все экземпляры классификатора совместно используют общее значение данного свойства.

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

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

При моделировании класса часто возникает потребность задать ему свойства, унаследованные от более общих классов и, наоборот, предоставить возможность более специализированным классам наследовать особенности данного. Такая семантика легко обеспечивается для классов средствами UML. Можно определить и такие классы, у которых нет потомков. Они называются листовыми и задаются в UML с помощью свойства leaf (лист), написанного под именем класса.

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

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

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

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

ровно один экземпляр – такой класс называют одиночным (Singleton);

заданное число экземпляров;

произвольное число экземпляров – вариант по умолчанию.

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

 

Рис. 6.83. Кратность

 

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

В UML определены четыре стандартных стереотипа, применимые к классам:

metaclass – определяет классификатор, все объекты которого являются классами;

powertype – определяет классификатор, все объекты которого являются потомками данного родителя;

stereotype – определяет, что данный классификатор является стереотипом, который можно применить к другим элементам;

utility – определяет класс, атрибуты и операции которого находятся в области действия всех классов.

Суммируя сказанное, получаем, что хорошо структурированный классификатор обладает следующими свойствами:

наделен как структурными, так и поведенческими аспектами;

внутренне согласован и слабо связан с другими классификаторами;

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

его семантика и назначение не допускают неоднозначного толкования;

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

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

Изображая классификатор в UML, принимают во внимание следующие рекомендации:

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

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

 

 

 

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

Отношение ассоциации (Association relationship)

Отношение обобщения (Generalization relationship)

Отношение агрегации (Aggregation relationship)

Отношение композиции (Composition relationship)

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

 

 

 

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

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

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

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

В качестве простого примера ненаправленной бинарной ассоциации можно рассмотреть отношение между двумя классами – классом Компания и классом Сотрудник (рис. 6.84.). Они связаны между собой бинарной ассоциацией Работает, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен следующий порядок чтения следования классов – сотрудник работает в компании.

 

 

Рис. 6.84. Графическое изображение ненаправленной бинарной ассоциации между классами

 

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

В качестве простого примера направленной бинарной ассоциации можно рассмотреть отношение между двумя классами – классом Клиент и классом Счет (рис. 6.85.). Они связаны между собой бинарной ассоциацией с именем Имеет, для которой определен порядок следования классов. Это означает, что конкретный объект класса Клиент всегда должен указываться первым при рассмотрении взаимосвязи с объектом класса Счет. Другими словами, эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

 

 

Рис. 6.85. Графическое изображение направленной бинарной ассоциации между классами

 

Частный случай отношения ассоциации – так называемая исключающая ассоциация (Xor–association). Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации (рис. 6.86.), рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

 

 

Рис. 6.86. Графическое изображение исключающей ассоциации между тремя классами

 

Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n–арной ассоциацией.

n–арная ассоциация (n–ary association) – ассоциация между тремя и большим числом классов.

Каждый экземпляр такой ассоциации представляет собой упорядоченный набор (кортеж), содержащий n экземпляров из соответствующих классов. Такая ассоциация связывает отношением более чем три класса, при этом класс может участвовать в ассоциации более чем один раз. Каждый экземпляр n–арной ассоциации представляет собой n–арный кортеж, состоящий из объектов соответствующих классов. В этом контексте бинарная ассоциация является частным случаем n–арной ассоциации, когда значение n=2, но имеет собственное обозначение. Бинарная ассоциация – это специальный случай n–арной ассоциации.

Графически n–арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Сам же ромб соединяется с символами классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя n–арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Однако порядок классов в n–арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется.

В качестве примера тернарной ассоциации можно рассмотреть отношение между тремя классами: Сотрудник, Компания и Проект. Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию о проектах, реализуемых в компании, и о сотрудниках, участвующих в выполнении отдельных проектов (рис. 6.87.).

 

 

Рис. 6.87. Графическое изображение тернарной ассоциации между тремя классами

 

Класс может быть присоединен к линии ассоциации пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей n–арной ассоциации, а сама n–арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация является классом с соответствующим обозначением в виде прямоугольника и самостоятельным элементом языка UML – ассоциацией классом (Association class).

Ассоциация–класс (Association class) – модельный элемент, который одновременно является ассоциацией и классом. Ассоциация класс может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации.

Как уже упоминалось, отдельный класс в ассоциации может играть определенную роль в данной ассоциации. Эта роль может быть явно специфицирована на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – концевая точка ассоциации или конец ассоциации (Association end), который графически соответствует точке соединения линии ассоциации с отдельным классом.

Конец ассоциации (Association end) – концевая точка ассоциации, которая связывает ассоциацию с классификатором.

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

Роль (Role) – имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте. Роль может быть статической или динамической.

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

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

Так, для примера (рис. 6.87.) кратность "1" для класса Компания означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса Сотрудник означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Вместо кратности "1..*" нельзя записать только символ "*", поскольку последний означает кратность "0..*". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Такая кратность приемлема в ситуациях, когда в компании вообще не выполняется никаких проектов.

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

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

 

 

<== предыдущая лекция | следующая лекция ==>
Диаграммы деятельностей | Отношение обобщения
Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 734; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.088 сек.