5.4. Диаграммы классов Общие сведения

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

Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Например, счет Джо - это объект. Типом такого объекта можно считать счет вообще, то есть "Счет" (account) - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Класс Account содержит идентификационный номер клиента и действия, проверяющие его. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. 5.10.

На этой диаграмме классов показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Устройство чтения карточек, Счет, Экран ATM и Кассовый аппарат. Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, у класса Счет имеется три атрибута: Номер счета, Регистрационный номер и Баланс. В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Счет имеется четыре операции: Открыть счет, Снять деньги, Вычесть сумму денег из счета и Проверить наличие денег.

Связывающие классы линии отражают взаимодействие между классами. Так, класс Счет связан с классом Экран ATM, потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Устройство чтения карточек не связан с классом Кассовый аппарат, поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Номер счета, Регистрационный номер и Баланс являются закрытыми атрибутами класса Счет. Кроме того, операции Вычесть сумму из счета и Проверить наличие денег также закрыты для этого класса.

Рис. 5.10. Диаграмма классов для варианта использования "Снять деньги"

Разработчики используют диаграммы Классов для реального создания классов. Такие CASE-средства, как Rational Rose, могут генерировать основу кода классов, которую затем программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы системы -понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. Если между сообщающимися классами не определено никаких связей, это также будет видно на диаграмме. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования, можно создавать также более общие диаграммы, охватывающие все системы или подсистемы целиком.

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

Существуют три различных точки зрения на построение диаграмм классов:

• концептуальная точка зрения. Если диаграммы классов рассматриваются с концептуальной точки зрения, то они будут отображать понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле, концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как независимую от средств реализации (языка программирования);

• точка зрения спецификации. В этом случае модель спускается на уровень ПО,

• но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

• точка зрения реализации. В этом случае модель действительно определяет реализацию классов ПО. Эта точка зрения является наиболее распространенной среди программистов.

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

При построении диаграммы точка зрения должна быть ясной и единственной. При чтении диаграммы следует выяснить, с какой точки зрения она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись.

Точка зрения на диаграммы классов не является собственно формальной частью UML, однако при построении и анализе моделей она является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают точку зрения реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.