Ограничения. 
Разработка и эксплуатация информационных систем

При построении диаграмм классов на них отображаются различные ограничения.

На рис. 3.3 показано, что Заказ может быть сделан одним-единственным Клиентом. Диаграмма также подразумевает, что каждая Позиция Заказа рассматривается отдельно: можно заказать 40 коричневых штук, 40 голубых штук и 40 красных штук, а не 40 коричневых, голубых и красных штук. Далее, диаграмма говорит, что Корпоративный клиент располагает кредитным лимитом, а Частный клиент — нет.

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

БОЛЕЕ СЛОЖНЫЕ ПОНЯТИЯ

Понятия, описанные выше, соответствуют основным нотациям на диаграмме классов. Эти понятия являются самыми первыми, с которыми следует познакомиться и которые необходимо освоить, поскольку с ними связаны 90% деятельности по построению диаграмм классов.

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

Стереотипы. В объектно-ориентированных проектах нередко можно столкнуться с такой ситуацией, когда один класс выполняет практически все функции системы, зачастую посредством одного огромного метода, а другие классы не делают в основном ничего, кроме инкапсуляции данных. Такое решение никак нельзя назвать удачным, поскольку при этом данный класс (условно можно назвать его «регулятором») слишком сложен и работать с ним трудно.

Чтобы улучшить такой проект, следует перенести поведение «регулятора» к другим, сравнительно незанятым объектам, благодаря чему эти объекты становятся более интеллектуальными и функционально нагруженными. «Регулятор» при этом превращается в «координатора». «Координатор» отвечает за выполнение задач в определенной последовательности, а другие объекты знают, как выполнять эти задачи.

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

Стереотипы обычно изображаются с помощью текста, заключенного в кавычки («управляющий объект»), однако они могут также изображаться с помощью пиктограммы.

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

Множественная и динамическая классификация. Понятие «классификация» касается связи между объектом и его типом.

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

Отметим, что множественная классификация отличается от множественного наследования. При множественном наследовании тип может иметь много супертипов, но для каждого объекта должен быть определен только один тип. Множественная классификация допускает принадлежность объекта многим типам без определения для этих целей какого-либо специального типа.

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

Если используется множественная классификация, то необходимо четко определить, какие сочетания являются допустимыми. Это делается с помощью дискриминатора, который помечает ассоциацию-обобщение и характеризует сущность подтипов. Несколько подтипов могут характеризоваться одним и тем же дискриминатором. Все подтипы с одним и тем же дискриминатором являются непересекающимися. Это означает, что любой экземпляр супертипа может быть экземпляром только одного из подтипов, описываемых данным дискриминатором. Удачный способ изобразить такое обобщение графически — это свести ассоциации всех подклассов к одной треугольной стрелке с одним дискриминатором, как показано на рис. 3.4. Альтернативный способ — изобразить несколько стрелок с одинаковыми текстовыми метками.

Дискриминатор может быть помечен как {полный} (что является дополнительным ограничением). Это означает, что любой экземпляр суперкласса должен быть экземпляром одного из подклассов в данной группе. (Суперкласс в этом случае является абстрактным.).

В качестве иллюстрации отметим следующие допустимые сочетания подтипов на диаграмме: (Женщина, Пациент, Медсестра); (Мужчина, Физиотерапевт); (Женщина, Пациент) и (Женщина, Доктор, Хирург). Отметим также, что такие сочетания, как (Пациент, Доктор) и (Мужчина, Доктор, Медсестра), являются недопустимыми: первое не включает типа, определенного {полным} дискриминатором «Пол», а второе включает сразу два типа, определенных одним и тем же дискриминатором «Роль». Однозначной классификации соответствует (по определению) единственный, непомеченный дискриминатор.

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

Динамическая классификация допускает изменение типа объектов в рамках структуры подтипов, а статическая классификация этого не допускает. Статическая классификация проводит границу между типами и состояниями, а динамическая классификация объединяет эти понятия.

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

Агрегация и композиция. Агрегация представляет собой связь «часть-целое» и является одним из наиболее часто используемых приемов моделирования (например, можно сказать, что двигатель и колеса являются частями автомобиля).

В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции объект-часть может принадлежать только единственному целому и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.

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

На рис. 3.6 показаны примеры агрегации и композиции. Согласно данной диаграмме Многоугольник состоит из упорядоченной совокупности Вершин. Эти Вершины могут изменяться при изменении Многоугольника, вследствие чего применяется агрегация. Композиция применяется для связи между Многоугольником и Графическим объектом.

Графический объект содержит такие атрибуты, как цвет и текстура. Он рассматривается отдельно от Многоугольника, поскольку многие графические элементы могут использовать такой набор атрибутов. Связь между Многоугольником и Графическим объектом определяется как композиция. Таким образом, показывается, что данный Графический объект создается и уничтожается вместе с данным Многоугольником и не может быть изменен. Разумеется, можно изменить атрибуты Графического объекта, но невозможно заменить один Графический объект другим.

Класс ассоциаций. Он позволяет определять для ассоциаций атрибуты, операции и другие свойства, как это показано на рис. 3.7.

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

Это можно сделать, дополнив ассоциацию атрибутом типа «интервал Времени». Можно включить этот атрибут в класс Личность, однако на самом деле он характеризует не Личность, а ее связь с Компанией, которая будет меняться при смене работодателя.

На рис. 3.8 показан другой способ представления данной информации: преобразование Работы в обычный класс (множественность при этом также подвергается соответствующему преобразованию). В данном примере каждый из классов в первоначальной ассоциации обладал однозначной ролью по отношению к классу Работа.

Таким образом, класс ассоциаций дает возможность определить дополнительное ограничение, согласно которому двум участвующим в ассоциации объектам может соответствовать только один экземпляр класса ассоциаций. Диаграмма на рис. 3.7 не допускает, чтобы Личность могла более чем один раз работать в одной и той же Компании. Если необходимо, чтобы такое допускалось, то Работу следует преобразовать в обычный класс, как это сделано на рис. 3.8.