Другие свойства

В процессе разработки абстракций вам чаще всего придется использовать про­стые зависимости и обобщения, а также ассоциации с именами, кратностями и ро­лями. В большинстве случаев базовых форм этих трех отношений вам будет вполне достаточно для передачи важнейших черт семантики моделируемых взаимосвязей. Но иногда все же возникает необходимость визуализировать и специфицировать другие особенности, такие как композитное агрегирование, навигация, дискриминанты, классы-ассоциации, а также специальные виды зависимостей и обобщений. Эти и многие другие особенности можно выразить на языке UML, однако предстоит воспользоваться концепциями более высокого уровня сложности (см. главу 10). Зависимости, обобщения и ассоциации являются статическими сущностями, определенными на уровне классов. В UML эти отношения обычно визуализируют в виде диаграмм классов (см. главу 8).

Приступая к моделированию на уровне объектов - особенно при работе с динамическими кооперациями объектов - вы встретите еще два вида отношений:

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

Типичные приемы моделирования Простые зависимости

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

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

Например, на рис. 5.8 показано несколько классов, взятых из системы, управ­ляющей распределением студентов и преподавателей на университетских курсах. Зависимость направлена от класса РасписаниеЗанятий к классу Курс, поскольку последний используется в операциях add и remove класса РасписаниеЗанятий. Если вы приводите полную сигнатуру операции, как на этом рисунке, то зави­симости показывать не обязательно, поскольку имя класса уже явно присутствует в сигнатуре. Иногда продемонстрировать зависимость все же имеет смысл, осо­бенно если сигнатуры операций скрыты или в модели показаны другие отношения, в которых участвует используемый класс. На рис. 5.8 представлена еще одна зависимость, не предполагающая участия Классов, а скорее моделирующая обычную для языка C++ идиому. Стрелка, на­правленная от класса Итератор, свидетельствует о том, что он использует класс

РасписаниеЗанятий, который, однако, об этом ничего не «знает». Зависимость помечена стереотипом friend, который говорит, что она представляет отношение дружественности, как в языке C++. (Другие стереотипы отношений рассматрива­ются в главе 10.)

Одиночное наследование

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

Моделирование отношений наследования осуществляется в таком порядке:

1. Найдите атрибуты, операции и обязанности, общие для двух или более клас­сов из данной совокупности.

2. Вынесите эти элементы в некоторый общий класс (если надо, создайте но­вый, но следите, чтобы уровней не оказалось слишком много).

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

На рис. 5.9 вы видите несколько классов, взятых из приложения по организа­ции работы трейдеров. Здесь показано отношение обобщения, которое от четырех классов - РасчетныйСчет, Акция, Облигация и Собственность - направле­но к более общему классу ЦенныеБумаги. Он является родителем, а остальные -его потомками. Каждый специализированный класс - это частный случай класса ЦенныеБумаги. Обратите внимание, что в классе ЦенныеБумаги есть две опе­рации - presentValue (текущаяСтоимость) и history (история). Это значит, что все его потомки наследуют данные операции, а заодно и все остальные атри­буты и операции родителя, которые могут не изображаться на рисунке.

Имена ЦенныеБумаги и presentValue на рисунке намеренно выделены курсивом. Дело в том, что, создавая иерархию подобного рода, часто приходится сталкиваться с нелистовыми классами, которые неполны или для которых не может существовать объектов. Такие классы называются абстрактными (см. гла­ву 9), и на языке UML их названия пишутся курсивом, как в приведенном приме­ре. Данное соглашение применимо и к операциям (например, presentValue/; оно означает, что у операции есть сигнатура, но в других отношениях она неполна и требует реализации на более низком уровне абстракции (см. главу 9). В нашем примере все четыре непосредственных потомка класса ЦенныеБумаги конкрет­ны (то есть не абстрактны) и реализуют операцию presentValue.

Иерархия «обобщение/специализация» не обязательно ограничивается двумя уровнями. Как видно из рисунка, вполне допустимо существование более двух уровней наследования. АкцияСМалымКапиталом и АкцияСБолыпимКапиталом -потомки класса Акция, который, в свою очередь, является потомком класса Цен­ныеБумаги. Последний является базовым классом, поскольку не имеет родите­лей. Классы же АкцияСМалымКапиталом и АкцияСБольшимКапиталом - лис­товые, поскольку не имеют потомков. Наконец, класс Акция имеет как родителей, так и потомков, а следовательно, не является ни листовым, ни базовым.

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

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