Диаграммы классов.
Общие сведения.
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Например, счет Джо - это объект. Типом такого объекта можно считать счет вообще, то есть "Счет" (account) - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Класс Account содержит идентификационный номер клиента и действия, проверяющие его. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или кооперативных диаграмм, Диаграмма классов для варианта использования "Снять деньги.
Рис 10. Диаграмма классов для варианта использования "Снять деньги".
На диаграмме классов показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса:
№ |
Имя класса |
Содержание |
1 |
Card Reader |
Устройство для чтения карточек |
2 |
Account |
Счет |
3 |
ATM Screen |
Экран ATM |
4 |
Cash Dispenser |
Кассовый аппарат |
Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части.
В первой содержится имя класса, во второй - его атрибуты. Атрибут — это некоторая информация, характеризующая класс.
Например, у класса Account (счет) имеется три атрибута:
№ |
Атрибут |
Содержание |
1 |
Account Number |
Номер счета |
2 |
PIN |
Идентификационный номер |
3 |
Balance |
Баланс |
В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Account имеется четыре операции:
№ |
Операция |
Содержание |
1 |
Open |
Открыть счет |
2 |
Withdraw Funds |
Снять деньги |
3 |
Deduct Funds |
Вычесть сумму денег из счета |
4 |
Verify Funds |
Проверить наличие денег |
Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen (экран ATM), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct Funds и Verify Funds также закрыты для этого класса.
Разработчики используют диаграммы классов для реального создания классов. CASE-средства, генерируют основу кода классов, которую затем программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы системы - понять ее проект.
Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами.
Если между сообщающимися классами не определено никаких связей, это также будет видно на диаграмме. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования, можно создавать также более общие диаграммы, охватывающие все системы или подсистемы целиком.
Перед тем, как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет серьезное отношению к тому, что описывается с помощью модели.
Существуют три различных точки зрения на построение диаграмм классов:
№ |
Точка зрения |
Характерные особенности |
Уровень пользователей |
1 |
Концептуальная модель |
Диаграммы классов отображают понятия изучаемой предметной области. Эти понятия, естественно, соответствуют реализующим их классам, однако прямое соответствие зачастую отсутствует. В общем, концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как независимую от средств реализации (языка программирования) |
Архитектор проекта, аналитик, заказчик, менеджер проекта |
2 |
Спецификация программного обеспечения |
В этом случае модель спускается на уровень ПО, но рассматриваются не программная реализация классов, а только интерфейсы. Интерфейс класса - это набор операций класса, видимых извне. |
Менеджер проекта, программист |
3 |
Программная реализации |
Модель определяет реализацию классов программного обеспечения. Эта точка зрения наиболее распространена у программистов. |
Программист |
Понимание точки зрения крайне важно как для построения, так и для чтения диаграмм классов. К сожалению, различия между ними не столь отчетливы, и большинство разработчиков при построении диаграмм допускают смешение различных точек зрения.
При построении диаграммы точка зрения должна быть ясной и единственной. При чтении диаграммы следует выяснить, с какой точки зрения она строилась. Для правильной интерпретации диаграммы классов, то без такого знания не обойтись.
Точка зрения на диаграммы классов не является собственно формальной частью UML, однако при построении и анализе моделей она является крайне важной.
Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают точку зрения реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к программному обеспечению должно выполняться с концептуальной точки зрения.
Стереотипы классов.
Стереотипы - это механизм, позволяющий разделять классы на категории.
Допустим, например, вы хотите найти все формы в вашей модели. Для этого можно создать стереотип Form (форма) и назначить его всем окнам вашего приложения. При поиске форм в дальнейшем надо только искать классы с этим стереотипом.
В языке UML определены три основных стереотипа:
№ |
Стереотип класса |
Содержание |
1 |
Boundary (граница) |
Пограничные классы (boundary classes) - классы, которые расположены на «границе» системы и всей окружающей среды. Они включают: формы, отчеты, интерфейсы: с аппаратурой (такой как принтеры или сканеры) с другими системами. Пограничные классы можно обнаружить при детальном анализе диаграмм вариантов использования. |
2 |
Entity (объект) |
Классы-сущности (entity classes) содержат информацию, сохраняемую постоянно. Классы-сущности обычно можно обнаружить в потоке событий и на диаграммах взаимодействия. Классы-сущности имеют наибольшее значение для пользователя, и потому их называют терминами из предметной области. |
3 |
Control (управление) |
Управляющие классы (control classes) - классы, отвечающие за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Как было показано в разд. 2.4.4, управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности - остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам. По этой причине управляющий класс часто называют классом-менеджером.
|
Пограничные классы
Пограничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.
Для поиска пограничных классов, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один пограничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой.
Обратите внимание, что необязательно создавать уникальные пограничные классы для каждой пары действующее лицо - вариант использования. Например, если два действующих лица инициируют один и тот же вариант использования, они могут использовать общий пограничный класс для взаимодействия с системой.
Изучение диаграмм вариантов использования может помочь обнаружить нужные пограничные классы.
Классы-сущности
Классы-сущности (entity classes) содержат информацию, сохраняемую постоянно. Например, в системе работы с данными о сотрудниках таким классом является класс Employee (сотрудник). Классы-сущности обычно можно обнаружить в потоке событий и на диаграммах взаимодействия. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области.
Часто для каждого класса-сущности создают таблицу в базе данных. В этом заключается еще одно отличие от типичного подхода к конструированию системы. Вместо того, чтобы с самого начала задать структуру базы данных, у нас теперь есть возможность разрабатывать ее на основе информации, получаемой из объектной модели. Это позволяет отслеживать соответствие всех полей базы данных и требований системы. Требования определяют поток событий. ПЬток событий определяет объекты, классы и атрибуты классов. Каждый атрибут класса-сущности становится полем в базе данных. Применяя такой подход, можно легко отслеживать соответствие между полями базы данных и требованиями к системе, что уменьшает вероятность сбора ненужной информации.
Управляющие классы
Рассмотрим теперь управляющие классы (control classes). Это классы, отвечающие за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности - остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам. По этой причине управляющий класс часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок.
С помощью этих типов управляющих классов можно легко изолировать функциональность системы. Инкапсуляция в один класс, например, координации безопасности, может минимизировать последствия вносимых изменений. Любые изменения отвечающей за безопасность логики системы затронут только менеджера безопасности.
Помимо упомянутых выше стереотипов можно создавать и свои собственные стереотипы.
Механизм пакетов
Один из подходов к решению проблемы сложности систем ПО заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package).
Пакеты применяют для группирования классов, обладающих некоторой общностью. На языке UML пакет изображают следующим символом:
Можно объединять классы исходя из любых соображений. Однако, существует несколько наиболее распространенных подходов.
№ |
Подход к формированию пакетов |
Результат применения подхода |
Возможные преимущества (Замечания) |
1 |
Группирование по стереотипу |
В результате получают пакеты с классами-сущностями, с пограничными классами, с управляющими классами и т.д. |
Подход полезен с точки зрения размещения готовой системы, так как все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете. |
2 |
Группирование по функциональности |
Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками); Reporting (Подготовка отчетов); Error Handling (Обработка ошибок). |
Преимущество подхода заключается в возможности повторного использования. При соответствующем к группировании классов, можно получить практически не зависящие друг от друга пакеты. Например, можно затем взять пакет Security и использовать в других приложениях. |
3 |
Комбинированное группирование |
На высоком уровне, например, можно сгруппировать классы по функциональности, создав пакет Security. Внутри нее можно создать другие пакеты, сгруппировав отвечающие за безопасность классы по функциональности или по стереотипу. |
Для дальнейшей организации классов пакеты можно вкладывать друг в друга. |
Механизм пакетов применим к любым элементам модели, а не только к классам.
Если для группирования классов не использовать некоторые эвристики, то оно становится произвольным.
Одна из них, которая в основном используется в UML - это зависимость.
Зависимость между двумя пакетами существует в том случае, если между любыми двумя классами в пакетах существует любая зависимость. Таким образом, диаграмма пакетов (рис. 11) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними.
Строго говоря, пакеты и зависимости являются элементами диаграммы классов, то есть диаграмма пакетов - это всего лишь форма диаграммы классов в укрупненном виде.
Рис. 11 Диаграмма пакетов
Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь за собой изменения в другом. Что касается классов, то причины для зависимостей могут быть самыми разными:
один класс посылает сообщение другому;
один класс включает часть данных другого класса;
один класс использует другой в качестве параметра операции.
Если класс меняет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу.
В идеальном случае только изменения в интерфейсе класса должны воздействовать на другие классы.
Искусство проектирования больших систем включает в себя минимизацию зависимостей - таким способом снижается воздействие изменений и требуется меньше усилий на их внесение.
Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в вашей системе, однако они помогают выделить эти зависимости, а после того, как они все окажутся на виду, остается только поработать над снижением их количества.
Диаграммы пакетов можно считать основным средством управления общей структурой системы.
Пакеты являются жизненно необходимым средством для больших проектов. Их следует использовать в тех случаях, когда диаграмма классов, охватывающая всю систему в целом и размещенная на единственном листе бумаги формата А4, становится не читаемой.
Пакеты особенно полезны при тестировании. Каждый пакет при этом может содержать один или более тестовых классов, с помощью которых проверяется поведение пакета.