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

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

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

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

Для того чтобы смоделировать кооперацию, необходимо:

• Идентифицировать механизм, который мы собираемся моделировать. Механизм представляет некоторую функциональную или поведенческую часть моделируемой системы, полученную в результате взаимодействия совокупности классов, интерфейсов и прочих сущностей.
• Для каждого механизма идентифицировать классы, интерфейсы и прочие кооперации, которые участвуют в данной  кооперации, а также связи между этими сущностями.
• Использовать сценарии для тестирования всех этих сущностей. На данном этапе выявляются части модели, которые были пропущены, а также те, которые семантически неверны.
• Убедиться, что все элементы наполнены правильным содержимым. Что касается классов, для начала обеспечьте оптимальный баланс обязанностей. Затем со временем проработайте конкретные атрибуты и операции.

В приведенном ниже примере показан набор классов, описывающих реализацию автономного робота. Акцент сделан на классы, связанные с механизмом перемещения робота по заданному пути. Вы найдете здесь один абстрактный класс Motor (Мотор) с двумя конкретными потомками – SteeringMotor (МоторПоворотногоМеханизма) и MainMotor (ГлавныйМотор). Оба потомка наследуют от своего родителя Motor пять операций. И оба они, в свою очередь, представлены как часть другого класса – Driver (Привод). Класс PathAgent (АгентТраектории) имеет ассоциацию «один-к-одному» с Driver и «один-ко-многим» – с CollisionSensor (ДатчикСтолкновений). Никаких атрибутов и операций для PathAgent не показано, хотя его обязанности и заданы.

В этой системе участвует много других классов, но диаграмма, которую мы рассматриваем, сосредоточена только на перемещении робота. В то же время некоторые классы, представленные на ней, можно найти и на других диаграммах. Например, хотя это здесь и не показано, класс PathAgent кооперируется по меньшей мере с двумя другими: Environment (Окружение) и GoalAgent (АгентЦели) в механизме более высокого уровня, управляющем разрешением конфликтных ситуаций, в которых может оказаться робот. Классы CollisionSensor и Driver, а также их части кооперируются с классом FaultAgent (АгентОтказа) в составе механизма, отвечающего за непрерывную диагностику оборудования робота на предмет разнообразных ошибок. Фокусируя внимание на каждой из этих коопераций в разных диаграммах, вы создаете понятное представление о системе с разных точек зрения.