5. Діаграми класів, асоціації, атрибути, операції, узагальнення, обмеження, агрегація і композиція.
Диаграмма классов описывает типы объектов и различного рода статические отношения, которые существуют между ними.
Имеется два основных вида статических отношений:
ассоциации (например, клиент может взять напрокат ряд видеокассет);
подтипы (медсестра является разновидностью личности).
На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами.
Пример диаграммы классов.
Ассоциации представляют собой отношения между экземплярами классов (сотрудник работает в компании, компания имеет несколько офисов).
С концептуальной точки зрения ассоциации представляют концептуальные отношения между классами.
На диаграмме показано, что Заказ может поступить только от одного Клиента, а Клиент в течение некоторого времени может сделать несколько Заказов. Каждый из этих Заказов может содержать несколько Строк заказа, причем каждая Строка заказа должна соответствовать единственному Товару.
Каждая из ассоциаций имеет два конца ассоциации; при этом каждый из концов ассоциации присоединяется к одному из классов этой ассоциации. Конец ассоциации может быть явно помечен некоторой меткой. Такая метка называется именем роли.
Конец ассоциации также обладает кратностью, которая показывает, сколько объектов может участвовать в данном отношении. Символ «*» возле класса Заказ для ассоциации между классами Заказ и Клиент показывает, что с одним клиентом может быть связано много заказов; напротив, символ «1» показывает, что каждый из заказов может поступить только от одного клиента.
С точки зрения спецификации ассоциации представляют собой ответственности классов.
Например, существует один или более методов, связанных с классом Клиент, с помощью которых можно узнать, какие заказы сделал конкретный клиент. Аналогично в классе Заказ существуют методы, с помощью которых можно узнать, какой Клиент сделал конкретный Заказ и какие Строки заказа входят в этот Заказ.
Если же модель рассматривается с точки зрения реализации, можно исходить из предположения, что между связанными классами существуют указатели в обоих направлениях.
Атрибуты обозначают информацию, которой располагают объекты класса.
На концептуальном уровне атрибут «имя Клиента» указывает на то, что клиенты обладают именами. На уровне спецификации этот атрибут указывает на то, что объект Клиент может сообщить вам свое имя и обладает некоторым способом для установления имени. На уровне реализации объект Клиент содержит некоторое поле для своего имени (называемое также переменной экземпляра или элементом данных).
Операции представляют собой процессы, реализуемые некоторым классом.
Существует очевидное соответствие между операциями и методами класса. На уровне спецификации операции соответствуют общедоступным методам над некоторым типом. Обычно можно не показывать такие операции, которые просто манипулируют атрибутами, поскольку они и так подразумеваются. Однако иногда возникает необходимость показать, что данный атрибут предназначен только для чтения (read-only) или является неизменным (frozen), то есть его значение никогда не изменяется. В модели реализации можно также указать защищенные и закрытые операции.
видимость может принимать одно из трех значений: «+» общедоступная (public), «#» защищенная (protected) или «-» закрытая (private).
имя представляет собой строку символов.
список-параметров содержит разделенные запятой параметры, синтаксис которых аналогичен синтаксису атрибутов: <направление> <имя>: <тип> = <значение по умолчанию>. При этом дополнительным элементом является направление, которое применяется, чтобы показать характер использования параметра - для входа (in), выхода (out) или в обоих направлениях (inout). Если значение направления отсутствует, оно предполагается входным (in).
выражение-возвращающее-значение-типа содержит список разделенных запятой значений типов. Большинство разработчиков использует только один тип возвращаемого значения, но допускается использование и нескольких таких типов.
строка-свойств указывает значения свойств, которые применяются к данной операции.
Пример записи операции для счета клиента: + показатъСостояние (дата: Дата): Деньги.
Обобщение указывает отношение между общим и частным.
Одинаковые свойства можно поместить в общий класс Клиент (супер- тип), при этом класс Индивидуальный клиент и класс Корпоративный клиент будут выступать в качестве подтипов.
В модели уровня спецификации обобщение означает, что интерфейс подтипа должен включать все элементы интерфейса супертипа. Говорят, что интерфейс подтипа согласован с интерфейсом супертипа.
Другая сторона обобщения связана с принципом замещения. Можно подставить класс Корпоративный клиент в любой код, где требуется класс Клиент, и при этом все должно работать прекрасно. По существу, это означает, что если я написал код, предполагающий использование класса Клиент, то могу свободно использовать экземпляр любого подтипа класса Клиент. Класс Корпоративный клиент может реагировать на некоторые команды отличным от класса Клиент образом (используя полиморфизм), но это отличие не должно беспокоить вызывающий объект.
С точки зрения реализации обобщение связано с понятием наследования в языках программирования. Подкласс наследует все методы и поля суперкласса и может переопределять наследуемые методы.
Язык UML разрешает использовать для записи ограничений все что угодно. При этом необходимо лишь придерживаться правила: ограничения следует помещать в фигурные скобки ({}).
Полезные советы:
Выбор точки зрения для построения модели должен соответствовать конкретному этапу работы над проектом:
На этапе анализа стройте концептуальные модели.
Если вы работаете с программным обеспечением, сосредоточьте свое внимание на моделях спецификации.
Применяйте модели реализации только в тех случаях, когда иллюстрируете конкретный способ реализации.
Не надо строить модели для всего на свете; вместо этого следует сконцентрироваться на главных аспектах. Лучше иметь мало диаграмм, которые постоянно используются в работе и отражают все внесенные изменения, чем иметь дело с большим количеством забытых и устаревших моделей.
Самая большая опасность, связанная с диаграммами классов, заключается в том, что вы можете слишком рано увязнуть в деталях реализации. Чтобы этому противостоять, концентрируйте внимание на концептуальной точке зрения и точке зрения спецификации.
