3.4. Диаграммы классов
3.4.1. Общие сведения
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеются два основных вида статических связей:
ассоциации (например, клиент может сделать заказ);
подтипы (частный клиент является разновидностью клиента).
На диаграммах классов изображаются также атрибуты классов,
операции классов и ограничения, которые накладываются на связи между объектами.
На рис. 3.2 изображена типичная диаграмма классов.
Рис. 3.2. Диаграмма классов
Перед тем как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет важное отношению к тому, что описывается с помощью модели.
Построение диаграмм классов можно рассматривать в различных аспектах:
концептуальный аспект — диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования);
аспект спецификации — модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);
аспект реализации — модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.
Понимание аспекта имеет большое значение как для построения, так и для чтения диаграмм классов. К сожалению, различия между аспектами не столь отчетливы, и большинство разработчиков при построении диаграмм допускают их смешение.
При построении диаграммы необходимо выбрать единственный аспект. При чтении диаграммы следует выяснить, в соответствии с каким аспектом она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись.
Точка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. КонструкцииUMLможно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.
3.4.2. Ассоциации
На рис. 3.2 изображена простая модель классов, связанная с обработкой заказов клиентов. Опишем каждый фрагмент модели и рассмотрим его возможную интерпретацию с различных точек зрения.
Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов).
С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами. На диаграмме показано, что Заказ должен поступить от единственного Клиента, а Клиент в течение некоторого времени может сделать несколько Заказов. Каждый из этих Заказов содержит несколько Строк заказа, каждая из которых соответствует единственному Продукту.
Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.
Роль может быть явно поименована с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется "позиции заказа". Если такая метка отсутствует, роли присваивается имя класса-цели — таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).
Роль также обладает множественностью, которая показывает, сколько объектов может участвовать в данной связи. На рис. 3.2 символ "*" над ассоциацией между Клиентом и Заказом означает, что с одним Клиентом может быть связано много Заказов; символ "1" показывает, что любой Заказ может поступить только от одного Клиента.
В общем случае множественность указывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в связи. Символ "*" в действительности выражает диапазон "ноль-бесконечность": Клиент может и не сделать ни одного Заказа, а может сделать неограниченное количество Заказов (теоретически). Единица означает диапазон "один-один": Заказ должен быть сделан одним и только одним Клиентом.
На практике наиболее распространенными вариантами множественности являются "1", "*" и "0..1" (либо ноль, либо единица). В общем случае может использоваться единственное число (например, 11 для количества игроков в команде), диапазон (например, 2..4 для игроков в карты) или дискретная комбинация из чисел и диапазонов (например, 2,4 для количества дверей в автомобиле).
Ассоциации в аспекте спецификации представляют собой ответственности классов.
На рис. 3.2 подразумевается, что существуют методы (один или более), связанные с Клиентом, с помощью которых можно узнать, какие заказы сделал данный Клиент. Аналогично в классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал данный Заказ и какие Позиции Заказа строки входят в Заказ.
Если допустить, что имеются стандартные соглашения по именованию методов запросов, то можно извлечь из диаграммы наименования этих методов. Например, можно принять соглашение, в соответствии с которым однозначные связи реализуются посредством метода, который возвращает связанный объект, а многозначные связи реализуются посредством перечисления (enumeration) или итератора, указывающего на совокупность связанных объектов.
Диаграмма классов (см. рис. 3.2) также предполагает, что существуют некоторые механизмы обновления связей. Например, должен существовать некоторый способ связи конкретного Заказа с конкретным Клиентом. Детали этого способа на диаграмме отсутствуют.
Если же модель отражает аспект реализации, можно исходить из предположения, что между связанными классами существуют указатели в обоих направлениях. Диаграмма может теперь сообщить, что Заказ содержит поле, представляющее собой совокупность указателей на Строки заказа, а также содержит указатель на Клиента.
Рассмотрим теперь рис. 3.3. В основном он совпадает с рис. 3.2, за исключением того, что к ассоциациям добавлены стрелки. Эти стрелки показывают направление навигации.
Рис. 3.3.Диаграмма классов с направлениями навигации
На модели спецификаций таким образом можно показать, что Заказ обязан ответить на вопрос, к какому Клиенту он относится, а у Клиента соответствующая ответственность отсутствует. Вместо симметричных ответственностей показываются только односторонние. На диаграмме реализации это может означать, что Заказ содержит указатель на Клиента, но Клиент не указывает на Заказ.
Как можно увидеть, направление навигации является важной частью диаграмм спецификации и реализации. На концептуальных же диаграммах, как правило, направления навигации отсутствуют. Они появляются по мере того, как аспект меняется в сторону спецификации и реализации.
Если навигация указана только в одном направлении, то такая ассоциация называется однонаправленной. У двунаправленной ассоциации навигация указана в обоих направлениях. В языке UMLотсутствие стрелок у ассоциации трактуется следующим образом: направление навигации неизвестно, или ассоциация является двунаправленной. Для моделей спецификации и реализации предпочтительнее трактовать отсутствие стрелок как неопределенное направление навигации.
Двунаправленные ассоциации содержат дополнительное ограничение, которое заключается в следующем: две их роли являются инверсными (обратными) по отношению друг к другу. Это утверждение подобно понятию обратных функций в математике. По отношению к рис. 3.3 это означает, что каждая Строка заказа, связанная с некоторым Заказом, должна быть связана с конкретным Заказом-источником (в смысле направления навигации). Аналогично если взять какую-либо Строку заказа и взглянуть на Позиции Строки, соответствующие связанному с ними Заказу, то можно обнаружить Строку заказа — источник данной совокупности элементов. Указанное свойство остается справедливым для любой из трех точек зрения.