11.2.2. Категории связей. Связь-зависимость
В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association). При проектировании реляционных БД наиболее важны вторая и третья категории связей, поэтому о связях-зависимостях будет сказано только самое основное.
Зависимостьюназывают связь по применению, когда изменение в спецификации одного класса может повлиять на поведение другого класса, использующего первый класс. Чаще всего зависимости применяют в диаграммах классов, чтобы отразить в сигнатуре операции одного класса тот факт, что параметром этой операции могут быть объекты другого класса. Понятно, что если интерфейс второго класса изменяется, это влияет на поведение объектов первого класса. Простой пример диаграммы классов со связью-зависимостью показан нарис. 11.4.
Рис.
11.4.Диаграмма классов со связью-зависимостью
Зависимость показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость. Очевидно, что связи-зависимости существенны для объектно-ориентированных систем (в том числе и для ООБД). При проектировании реляционных БД непонятно, что делать с зависимостями (как воспользоваться этой информацией в реляционной БД?).
11.2.3. Связи-обобщения и механизм наследования классов в uml
Связью-обобщениемназывается связь между общей сущностью, называемойсуперклассом, или родителем, и более специализированной разновидностью этой сущности, называемойподклассом, или потомком. Обобщения иногда называютсвязями «is a», имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.
Объекты класса-потомка могут использоваться везде, где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми во множество объектов класса-предка. Графически обобщения изображаются в виде сплошной линии с большой незакрашенной стрелкой, направленной к суперклассу. В качестве первой иллюстрации, приведенной нарис. 11.5, воспользуемся классификацией летательных аппаратов срис. 10.12из предыдущей лекции. Нарис. 11.5показан пример иерархииодиночного наследования: у каждого подкласса имеется только один суперкласс.
Рис.
11.5.Иерархия одиночного наследования
классов
Одиночное наследование является достаточным в большинстве случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов. В качестве одного из разумных (не слишком распространенных) примеров рассмотрим диаграмму классов нарис. 11.6(для упрощения диаграммы имена атрибутов и операций указывать не будем).
Рис.
11.6.Пример множественного наследования
классов
На этой диаграмме классы СтудентиПреподавательпорождены из одного суперклассаЧеловекИзУниверситета. Вообще говоря, к классуСтудентотносятся те объекты классаЧеловекИзУниверситета, которые соответствуют студентам, а к классуПреподаватель– объекты классаЧеловекИзУниверситета, соответствующие преподавателям. Но, как это часто случается, многие студенты уже в студенческие годы начинают преподавать, так что могут существовать такие два объекта классовСтудентиПреподаватель, которым соответствует один объект классаЧеловекИзУниверситета. Итак, среди объектов классаСтудентмогут быть преподаватели, а некоторые преподаватели могут быть студентами. Тогда мы можем определить классСтудентПреподавательпутем множественного наследования от суперклассовСтудентиПреподаватель. Объект классаСтудентПреподавательобладает всеми свойствами и операциями классовСтудентиПреподавательи может быть использован везде, где могут применяться объекты этих классов. Так что полиморфизм по включению продолжает работать. Следует отметить, что множественное наследование, помимо того что не слишком часто требуется на практике, порождает ряд проблем, из которых одной из наиболее известных является проблема именования атрибутов и операций в подклассе, полученном путем множественного наследования. Например, предположим, что при образовании подклассовСтудентиПреподавательв них обоих был определен атрибут с именемномерКомнаты. Очень вероятно, что для объектов классаСтудентзначениями этого атрибута будут номера комнат в студенческом общежитии, а для объектов классаПреподаватель– номера служебных кабинетов. Как быть с объектами классаСтудентПреподаватель, для которых существенны оба одноименных атрибута (у студента-преподавателя могут иметься и комната в общежитии, и служебный кабинет)? На практике применяется одно из следующих решений:
запретить образование подкласса СтудентПреподаватель, пока в одном из суперклассов не будет произведено переименование атрибутаномерКомнаты;
наследовать это свойство только от одного из суперклассов, так что, например, значением атрибута номерКомнатыу объектов классаСтудентПреподавательвсегда будут номера служебных кабинетов;
унаследовать в подклассе оба свойства, но автоматически переименовать оба атрибута, чтобы прояснить их смысл; назвать их, например, номерКомнатыСтудентаиномерКомнатыПреподавателя.
Ни одно из решений не является полностью удовлетворительным. Первое решение требует возврата к ранее определенному классу, имена атрибутов и операций которого, возможно, уже используются в приложениях. Второе решение нарушает логику наследования, не давая возможности на уровне подкласса использовать все свойства суперклассов. Наконец, третье решение заставляет использовать длинные имена атрибутов и операций, которые могут стать недопустимо длинными, если процесс множественного наследования будет продолжаться от полученного подкласса.53)
Но, конечно, сложность проблемы именования атрибутов и операций несопоставимо меньше сложности реализации множественного наследования в реляционных БД. Поэтому при использовании UML для проектирования реляционных БД нужно очень осторожно использовать наследование классов вообще и стараться избегать множественного наследования.54)