Представление подтипов

Способ представления подтипов в UML показан на рис. 3.14. На этом рисунке до­пустимыми подтипами сущности КЛИЕНТ являются ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИ­ЩЕСТВО и КОРПОРАЦИЯ. В соответствии с рисунком, каждый клиент может иметь один, два или все три указанных подтипа. Для данной ситуации это не имеет смысла: клиент должен быть одного и только одного типа. Текущая версия UML не предоставляет способов для документирования взаимоисключаемости. Мож­но, однако, добавить в диаграмму соответствующее обозначение.

На рис. 3.15 представлена UML-версия диаграммы «сущность—связь», пока­занной ранее на рис. 3.11. Поскольку связь между сущностями РАБОТА и КЛИЕНТ имеет атрибут Плата, для несения этого атрибута выделена специальная сущ­ность РАБОТА_ДЛЯ_КЛИЕНТА. Такова стандартная практика при использовании средств UML. Обратите также внимание на представление рекурсивной связи КЕМ_ПРИВЕДЕН.

Конструкции ооп, введенные языком uml

Так как UML является объектно-ориентированной технологией, к классам сущ­ностей UML были добавлены некоторые конструкции ООП. Здесь мы только коснемся этих идей, а развитие им дадим в главе 18. Во-первых, классы всех сущ­ностей, которые должны храниться в базе данных, помечаются стереотипом

«Persistent» (устойчивый). Это означает, что существование данных должно продолжаться даже после того, как будет разрушен объект, их обрабатывавший. Проще говоря, это значит, что класс сущности должен храниться в базе данных.

Далее, UML допускает назначение атрибутов классам сущностей. Атрибуты класса (class attributes) отличаются от атрибутов сущностей тем, что они при­надлежат всему классу сущностей данного типа. Так, на рис. 3.16 атрибут Число-Пациентов сущности ПАЦИЕНТ является атрибутом всей совокупности сущностей этого типа, имеющихся в базе данных. ИсточникПоступления — это атрибут, до­кументирующий источник поступления всех пациентов, присутствующих в базе данных.

Как вы позже узнаете, в рамках реляционной модели такие атрибуты клас­сов просто негде хранить. Вместо того чтобы хранить атрибуты вроде ЧислоПаци-ентов в базе данных, они иногда вычисляются на этапе выполнения программы. В других случаях для хранения этих атрибутов выделяется специальный класс сущностей. Для класса сущностей ПАЦИЕНТ, изображенного на рис. 3.16, мож­но создать новую сущность под названием ИСТОЧНИК_ПОСТУПЛЕНИЯ_ПАЦИЕНТА, имеющую атрибуты ЧислоПациентов и ИсточникПоступления. В таком случае все сущности класса ПАЦИЕНТ будут связаны с сущностью ИСТОЧНИК_ПОСТУПЛЕНИЯ_ ПАЦИЕНТА.

Третьей новой особенностью является то, что UML использует объектно-ори­ентированную нотацию для обозначения видимости атрибутов и методов. Атри­буты, именам которых предшествует знак «+», являются открытыми, атрибуты со знаком «#» являются защищенными, а со знаком «-» — закрытыми. На рис. 3.16 атрибут Имя сущности ПАЦИЕНТ является защищенным.

Эти термины имеют корни в объектно-ориентированном программировании. Открытым (public) называется такой атрибут, который может читаться и изме­няться любым методом любого объекта. Термин защищенный (protected) означа­ет, что атрибут или метод доступен только для методов данного класса и его под­классов, а термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только для методов данного класса.

Наконец, в UML задаются ограничения и методы, для чего служит третий сегмент прямоугольника, изображающего класс сущностей. На рис. 3.16 на зна­чение атрибута НомерПациента налагается ограничение первичного ключа. Это означает просто, что НомерПациента является уникальным идентификатором. Кроме того, рис. 3.16 указывает, что должны быть созданы следующие методы: ПолучитьИмя() — для открытого доступа к атрибуту Имя (обратите внимание на знак «+» перед ПолучитьИмя(), ВвестиИмя() — для установки значения этого атри­бута, и ПолучитьРецепт() — для перебора совокупности сущностей класса РЕЦЕПТ, связанных с данной сущностью ПАЦИЕНТ.